Skip to content

Cephalon Engine Roadmap

Editable roadmap diagram: docs/cephalon-engine-roadmap.drawio

Planning baseline in this document reflects the repository state as of April 30, 2026.

Cephalon should become a modular runtime platform that can:

  • compose modules, capabilities, and policies deterministically
  • run across multiple hosts and transports without rewriting feature code
  • generate opinionated app shapes from blueprints instead of ad-hoc setup
  • ship as reusable packages, templates, and samples for other teams
  • grow later into package loading, workflow, orchestration, and AI-driven runtime scenarios

The foundation is no longer hypothetical. The repository already ships:

  • host-agnostic module contracts in Cephalon.Abstractions
  • configuration-driven engine composition in Cephalon.Engine
  • technology-profile modeling for future-facing workloads through Engine:Technologies and AppProfile.Technologies
  • baseline companion packages for AgenticWorkloads, EventDrivenIntegration, KnowledgeRetrieval, MultiTenancy, and EdgeNativeDelivery
  • assembly-based module discovery
  • module and capability policy toggles through Engine:Options
  • manifest v2 with engine version, module metadata, and capability source mapping
  • host adapters for ASP.NET Core and generic worker hosts
  • transport support for RestApi, JsonRpc, Grpc, GraphQL, ServerSentEvents, and WebSocket
  • OpenAPI + Scalar for REST-facing ASP.NET Core hosts
  • scaffold plans, scaffold generation, and a working CLI
  • a dotnet new template-pack baseline for the shipped blueprints
  • starter templates and a reference package for module authoring
  • an explicit package-assembly loading baseline with package manifest introspection
  • a baseline trust and capability-policy surface for package trust and REST boundary enforcement
  • sample apps per shipped blueprint
  • runtime failure policy baseline with fail-fast, capture-only, best-effort stop, and restart guards
  • operational health endpoints, diagnostics surface, and dependency-health contributor baseline for ASP.NET Core hosts
  • observability conventions for logs, metrics, tracing, and telemetry export guidance
  • a benchmark suite plus baseline guardrail validation for composition, strict trust-policy composition, runtime lifecycle, ASP.NET Core request logging, and scaffolding hot paths
  • a GitHub Actions release-validation workflow that runs the repo-native build, test, benchmark, and guardrail flow
  • a repo-native .NET readiness assessment flow plus a dedicated .NET 11 workflow lane that keep future-SDK validation separate from the stable net10.0 shipping baseline

That changes the plan materially:

  • we do not need another “start the engine” phase
  • we do need an “adopt this safely outside the repo” phase
  • we should prioritize SDK hardening, templates, samples, and operational polish before advanced platform features
  • public-surface hardening and compatibility guidance now sit inside that shipped SDK-adoption baseline rather than as vague follow-up work

The repository now has enough shipped runtime to separate three kinds of surface explicitly:

  • taxonomy-only vocabulary
  • catalog plus runtime truth
  • managed execution or provisioning ownership

That distinction matters because some technology packs already own real execution or control-plane loops, while others currently stop at descriptors, catalogs, and truthful introspection.

The next planning wave is therefore not “add more descriptors everywhere.” It is:

  • make surface maturity explicit through Engine surface maturity audit
  • keep intentional M0 and M1 surfaces honest instead of letting them read like unfinished M2 work
  • prove one narrow managed vertical slice in mixed-maturity families before widening catalog breadth; the behavior REST profile/runtime ownership, eventing core execution-binding plus abstraction-level execution-readiness catalog/operator surface, the opt-in eventing in-process subscription execution lane with bounded process-local retries and duplicate-completed execution suppression, the bounded POST /engine/event-publications operator action, the /engine/event-publications/runtime* publication runtime-state read seam, the optional Wolverine proof with bounded dispatch and subscription terminal-failure posture, agentics dispatcher plus abstraction-level run-state/operator-action, bounded process-local executor retry posture, bounded process-local duplicate-completed suppression, approval-required filter, and terminal-failure filter, and retrieval lexical index/query plus bounded query action, manual reindex, and opt-in background reindex lanes are current examples
  • keep Cephalon.MultiTenancy core narrow; Cephalon.MultiTenancy.Governance owns concrete membership, invitation, delivery dispatch/retry/status reconciliation, observation-store, tenant-administration, domain-ownership, proof-collection/polling, and governance-action proofs, while optional ASP.NET Core, HTTP delivery, SMTP delivery, SendGrid delivery, Mailgun delivery, Amazon SES delivery, Amazon SES delivery ASP.NET Core, Microsoft Graph delivery, Microsoft Graph Azure Identity, SendGrid delivery ASP.NET Core, and Mailgun delivery ASP.NET Core companions own routing, provider sender handoff, provider token-provider handoff, filtered observation rollup summaries, attention-category drill-downs, provider-message drill-downs, remediation hints, provider payload translation, optional SendGrid signed-webhook verification, bounded process-local signed-callback replay protection, observation-store-backed SendGrid event-id idempotency, optional Mailgun HMAC signed-webhook verification, bounded process-local Mailgun replay-token rejection, observation-store-backed Mailgun event-id idempotency, Amazon SES over SNS callback translation, opt-in SNS signature verification, bounded process-local SNS replay protection, observation-store-backed Amazon SNS message-id idempotency, opt-in verified SNS subscription confirmation, and opt-in verified SNS unsubscribe-confirmation observation without bloating the base pack. Actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond state transitions, distributed or provider-backed governance storage, identity-provider synchronization, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, distributed retry queues, cross-node retry leases, provider-specific or distributed callback inboxes, cross-node callback replay protection, distributed event-id ledgers, provider-specific delivery-status callback payload translation beyond the shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, public onboarding, and tenant-admin UI/backoffice flows remain later companion-owned work
  • use Cephalon.Behaviors, Cephalon.Behaviors.Http, Cephalon.Data, and the shipped edge provider packs as the current examples of truthful runtime ownership

The project board now tracks both delivered work and upcoming work through explicit sprint buckets:

  • Foundation Sprint 1: ENG-000, ENG-001, ENG-002, ENG-003, ENG-004
  • Foundation Sprint 2: ENG-006, ENG-007, ENG-008, ENG-009
  • Foundation Sprint 3: ENG-014, ENG-015, ENG-025
  • Adoption Sprint 0: ENG-016, ENG-017, ENG-018
  • Operational Sprint 0: ENG-019, ENG-020, ENG-021, ENG-024, ENG-023
  • Platform Sprint 0: ENG-012
  • Sprint 1: delivered ENG-005, ENG-026, and ENG-027, and opened the phase 2 operational gap-inventory track
  • Sprint 2: exporter packaging is now part of the shipped phase-2 baseline, Cassandra contact-point health plus ClickHouse analytics health plus Consul control-plane health plus Elasticsearch cluster health plus HTTP external API plus Kafka broker metadata plus Memcached cache plus MongoDB plus MQTT plus MySQL plus NATS plus Neo4j plus OpenSearch plus Oracle plus Postgres plus RabbitMQ plus Redis/cache plus SQL Server dependency-health packaging anchor the provider-specific follow-through, the shared diagnostics/event-id catalog now anchors the structured diagnostics baseline, and release validation now calls out the health/export convention suite explicitly
  • Sprint 3: runtime-answers follow-through, the shipped package distribution/provenance and signer-verification follow-through under ENG-011, the shipped ENG-013 execution-graph lifecycle/observability plus hosted-execution convention and agentic orchestration-link follow-through, the shipped ENG-022 suite-scaffold-shape baseline under #79, the shipped built-in MicroserviceSuite composition baseline under #80, the shipped multi-service suite sample baseline under #81, the shipped suite-governance and additive gateway/control-plane guidance baseline under #82, the shipped ENG-029 self-hosted OTLP follow-through slice, the shipped Azure Monitor first-vendor slice, the shipped AWS second-vendor slice, the shipped GCP third-vendor slice, the shipped Oracle Cloud managed-ingestion slice, the shipped DigitalOcean collector/defaults slice, the shipped VMware Tanzu proxy/defaults slice, the shipped Kubernetes collector/defaults slice, the shipped downstream Cloudflare/custom-provider authoring slice under #120, the shipped Grafana Cloud OTLP/header slice under #126, and the shipped New Relic native OTLP/api-key slice under #127
  • Sprint 4: shipped ENG-033 cross-platform validation/shell parity plus ENG-034 first-run adoption and environment-doctor work so install, validation, and first-run guidance now hold together outside the repo
  • Sprint 5: shipped ENG-035 external module-package lifecycle prove-out so published packages, trust policy, and runtime introspection are exercised end to end outside the repo-local assembly path
  • Sprint 6: shipped ENG-036 containerized local runtime and operations prove-out so Docker Desktop / WSL teams can validate startup, health, and telemetry handoff with a reproducible sample deployment shape
  • Sprint 7: shipped ENG-037 generated-app local package-feed bootstrap follow-through so freshly scaffolded apps can restore, build, and take the documented container path from a seeded or repointed package source without repo-only NuGet knowledge
  • Sprint 8: shipped ENG-038 generated-app published-output and deployment baseline so scaffolded apps now carry a deterministic folder-publish profile plus a validated smoke path from scaffold -> publish -> run from published output
  • Sprint 9: shipped ENG-039 generated-app Linux systemd deployment baseline so scaffolded apps now also carry self-hosted service assets plus a validated WSL systemd-analyze path for Linux-class deployment packaging
  • Sprint 10: shipped ENG-040 generated-app Windows Service deployment baseline so scaffolded apps now also carry self-hosted Windows install assets plus a validated install-preview path against published output without admin-only repo validation
  • Sprint 11: shipped ENG-041 generated-app IIS deployment baseline so scaffolded apps now also carry hosted Windows site/app-pool assets plus a validated ANCM web.config and install-preview path against published output without requiring a live IIS install
  • Sprint 12: shipped ENG-042 generated-app Azure App Service deployment baseline so scaffolded apps now also carry hosted Azure ZIP-deploy assets plus a validated run-from-package and Azure CLI preview path against published output without requiring live Azure credentials
  • Sprint 13: shipped ENG-043 generated-app Azure Container Apps deployment baseline so scaffolded apps now also carry hosted Azure source-deploy assets plus a validated Dockerfile build and Azure CLI preview path from the generated app root without requiring live Azure credentials
  • Sprint 14: shipped ENG-044 generated-app Kubernetes deployment baseline so scaffolded apps now also carry platform-neutral manifest/apply assets plus a validated Dockerfile build and kubectl kustomize preview path from the generated app root without requiring a live cluster
  • Sprint 15: shipped ENG-045 generated-app container-image publishing baseline so scaffolded apps now also carry provider-neutral build/tag/push assets plus a validated local-registry smoke path from the generated app root without requiring a cloud-specific registry contract
  • Sprint 16: open phase 8 with ENG-046, ENG-047, and ENG-048 so taxonomy, structured config, and host-agnostic contracts freeze before package or template drift starts
  • Sprint 17: deliver ENG-049 and ENG-050 so the relational-first data and eventing golden path exists before broader provider or security follow-through
  • Sprint 18: deliver ENG-051, ENG-052, and ENG-053 so identity/authorization, multi-tenancy/audit, and CLI/scaffolding/template/sample alignment land on top of the frozen phase-8 contract
  • Sprint 19: deliver ENG-055 and ENG-056 so validation, benchmarks, docs, XML comments, and reference-doc alignment close the phase-8 truthfulness gap before broader expansion claims
  • Sprint 20: shipped ENG-058 M1 ABT foundation — IAppBehavior, IBehaviorContext, BehaviorDispatcher, BehaviorExecutionSlot, CompatibilityMatrix, ABT-001–ABT-006 compatibility rules, hosting — 499/499 tests (commit 9d657da)
  • Sprint 21: shipped ENG-058 M2 HTTP Transport Pack — 7 HTTP bindings (rest, jsonrpc, graphql, graphql-sse, graphql-ws, sse, ws), LazyTransportBinding — 516/516 tests (commit c957966)
  • Sprint 22: shipped ENG-058 M3 Messaging Transport Pack — InMemory, RabbitMQ, Kafka bindings; M2 CTS leak fix — 527/527 tests (commit 9183407)
  • Sprint 23: shipped ENG-058 M4 Pattern Execution Strategies — 5 strategies (cqrs, event-driven, saga-step, process-manager, direct), ISagaStateStore, IProcessCheckpointStore, FrozenDictionary registry, IBehaviorContext.CorrelationId, IProcessCompletion — 575/575 tests (commit cc2ab0a)
  • Sprint 24 (M5): shipped ENG-058 M5 Source Generator — BehaviorSourceGenerator (analyzer + incremental generator), ABT0010–ABT0013, BehaviorRegistrationHints.g.cs, 584/584 tests (commit 8455b9a)
  • Sprint 24 (M6): shipped ENG-058 M6 Runtime Integration — BehaviorRuntimeContributor, IBehaviorAdvisory system, IBehaviorContext.EventStore, BehaviorDiagnostics 5100-5109, 592/592 tests (commit 62d386c)
  • Sprint 25: shipped ENG-054 MongoDB document-store provider — Cephalon.Data.MongoDB + Cephalon.EventSourcing.MongoDB, MongoDB.Driver 3.4.0 — 599/599 tests (commit f94dc28)
  • Sprint 26: shipped ENG-054 Redis key-value-store provider — Cephalon.Data.Redis + Cephalon.EventSourcing.Redis, StackExchange.Redis 2.8.16 — 607/607 tests
  • Sprint 27: shipped ENG-054 Neo4j graph-store provider — Cephalon.Data.Neo4j + Cephalon.EventSourcing.Neo4j, Neo4j.Driver 6.0.0 — 615/615 tests
  • Sprint 28: shipped ENG-054 Cassandra wide-column-store provider — Cephalon.Data.Cassandra + Cephalon.EventSourcing.Cassandra, CassandraCSharpDriver 3.22.0 — 624/624 tests
  • Sprint 29: shipped ENG-054 ClickHouse analytics-store provider — Cephalon.Data.ClickHouse + Cephalon.EventSourcing.ClickHouse, ClickHouse.Driver 1.0.2 — 632/632 tests
  • Sprint 30: shipped ENG-054 Elasticsearch + OpenSearch search-store provider — 4 packages, Elastic.Clients.Elasticsearch 8.17.0 + OpenSearch.Client 1.8.0 — 640/640 tests
  • Sprint 31: shipped ENG-054 Qdrant vector-store + NATS ledger-store provider — 4 packages, Qdrant.Client 1.17.0 + NATS.Net 2.7.3 — 648/648 tests. ENG-054 Track 1 complete: all 9 non-relational provider families delivered. The same sprint also shipped ENG-058-T30 behavior-aware REST endpoint helper follow-through: MapBehaviorRestGroup(...), versioned OpenAPI metadata defaults, XML-comment enrichment, and showcase cart route deduplication over the behavior dispatcher, ENG-058-T31 OpenAPI XML-comment deduplication follow-through so behavior <summary> and <remarks> render as distinct Scalar/OpenAPI summary and description text, ENG-058-T32 named OpenAPI document selection via BehaviorRestEndpointGroup.ApiVersion(major), ENG-058-T33 versioned OpenAPI config canonicalization around OpenApi:EnabledVersions plus OpenApi:DefaultVersion, ENG-058-T34 versioned Scalar doc-link behavior, ENG-058-T35 canonical Scalar links plus /api/v{major} REST-route alignment, ENG-058-T36 configurable docs-route surfaces and module-major REST defaults, ENG-058-T37 shared BehaviorApiSurface canonical routing across the generic non-REST behavior HTTP bindings, ENG-058-T38 canonical ApiRoutes:Prefixes defaults for both built-in and generic HTTP transport surfaces, ENG-058-T40 public REST documentation separation plus tag-metadata follow-through so module-owned REST groups now own the published REST OpenAPI/Scalar surface, ENG-058-T41 cleanup that removed behavior-declared REST so MapEndpoints(...) plus MapBehaviorRestGroup(...) are no longer the main REST authoring story, ENG-058-T43 module-owned behavior authoring baseline so one module can explicitly own both internal-only and REST-exposed behaviors through BehaviorModuleBase and RestBehaviorModuleBase, ENG-058-T44 the single-surface REST behavior module DSL plus AutoRegister=false default so REST behavior modules can declare public routes and internal ownership in one pass through ConfigureRestBehaviors(...), ENG-058-T46 transport-neutral behavior results plus optional REST result-envelope projection so behaviors can return raw TOut or BehaviorResult<T> in the core contract while ASP.NET Core can still publish ResultModel<T> / ResultModelError on the REST wire when the host opts into ApiRoutes:ResultEnvelope:Enabled, ENG-058-T47 plural REST error-envelope follow-through so validation and other multi-reason failures now flow through an errors collection backed by BehaviorFault.InnerFaults while OpenAPI generation keeps the same canonical plural contract, ENG-058-T48 showcase AddToCartBehavior authoring follow-through so the cart sample now demonstrates BehaviorResult<T>, multi-fault validation, checkout conflicts, and focused REST-envelope overrides in a concrete end-to-end module example, ENG-058-T49 concise no-payload BehaviorResult factories so common async-return branches can now say BehaviorResult.Invalid(...) / BehaviorResult.NotFound(...) / BehaviorResult.Conflict(...) without repeating <T> while docs call out the remaining Task.FromResult<BehaviorResult<TOut>>(...) inference edge case explicitly, ENG-058-T50 configurable documented REST response statuses plus default 500 so hosts can narrow or expand the status list shown in OpenAPI + Scalar through OpenApi:BehaviorRest:DocumentedStatusCodes while Cephalon now keeps 500 visible by default and stops forcing 400/404 when that list is narrowed, and ENG-058-T51 concise Result<T> / Result aliases so new behavior authoring can use Result<T> plus Result.*(...) while the legacy BehaviorResult<T> surface stays available as a compatibility alias and REST/OpenAPI recognizes both families. The transport surface now keeps GraphQL semantics schema-owned while still aligning GraphQL-family behavior endpoints with the same prefix/version policy used by the rest of the generic HTTP transport pack
  • Infrastructure Phase 1: solution filter files (core.slnf, data.slnf, observability.slnf, aspnetcore.slnf) + scaffolding scripts (New-ProviderPack.ps1, New-ObservabilityPack.ps1)
  • Infrastructure Phase 2: test assembly split — Cephalon.Tests monolith (648 tests) split into Cephalon.Tests.Support + Cephalon.Tests.Composition (327) + Cephalon.Tests.Hosting (200) + Cephalon.Tests.Tooling (121) — 648/648 tests
  • Sprint 32: backlog and roadmap alignment for all completed work through Sprint 31, status closeout for ENG-054/056/057
  • Sprint 33: EF projection contributor (IProjectionContributor), Wolverine dispatch observability (ActivitySource + Meter), validation script fix for post-test-split environment, ENG-051 closeout — 648/648 tests
  • Sprint 34: comprehensive engine audit — WebSocket [LoggerMessage] logging fix, flaky test fix, architecture inventory/recommendations docs, ENG-049/050/052/053/055 closeout (all phase-8 baseline acceptance met), ENG-059 benchmark expansion planned — 648/648 tests
  • Sprint 35: shipped ENG-059 runtime hot-path benchmark expansion — data layer dispatch, behavior dispatch, authorization evaluation, tenant resolution, event sourcing, outbox staging — 13 new benchmarks across 6 classes, guardrails 10→23, 648/648 tests
  • Sprint 31: shipped ENG-054 provider configuration follow-through — connection-string-native packs now share ConnectionStringName plus ConnectionString (Cephalon.Data.MongoDB, Cephalon.Data.Redis), URI-first packs now share UriName plus Uri (Cephalon.Data.Elasticsearch, Cephalon.Data.OpenSearch, Cephalon.Data.Neo4j, Cephalon.Data.Nats), named values resolve from the root ConnectionStrings or Uris sections as appropriate, packs fail fast when both settings are supplied, and the docs now call out the provider-family contract explicitly while Cassandra/Qdrant remain topology-first
  • Sprint 36: ENG-060 established the engine-owned database topology baseline so physical database roles, migration targets, outbox routing, and history stores stop drifting across provider packs
  • Sprint 37: ENG-061 is now shipped on top of that topology contract: Cephalon.Data.EntityFramework consumes Engine:Databases write/read roles directly, publishes role and migration metadata through the runtime surface, and supplies the migration-registration primitives that also let additive companion packs register truthful history-role execution
  • Sprint 38: ENG-062 is now shipped: Cephalon.Audit.EntityFramework provides the first durable audit-history baseline through Engine:Audit:History plus a selected engine-owned database role, defaulting to History, and the showcase sample now proves the topology end to end through configured WriteDb / ReadDb / HistoryDb roots for Docker-backed runs, separate read-side migrations, durable read-projection jobs staged in the write store, and the adoption-quality /api/v1/showcase/system/database-topology operator projection now promoted into the main /showcase operator console with derived operator insights, an ordered action plan, a shareable Markdown brief, and a downloadable self-describing handoff package for aligned-versus-drifting topology state
  • Sprint 31 follow-through: ENG-063 is now shipped on top of the first durable history baseline so audit history now includes a host-agnostic filtered-page reader contract, engine-owned retention settings, /engine/audit-history operator routes, and showcase-facing /api/v1/showcase/audit/history endpoints instead of staying write-only
  • Sprint 31 follow-through: ENG-064 is now shipped on top of the same durable history baseline so audit history now also includes a host-agnostic bounded export contract, Engine:Audit:History:Export, /engine/audit-history/export, and showcase-facing /api/v1/showcase/audit/history/export endpoints
  • Sprint 31 follow-through: ENG-065 is now shipped on top of the same topology baseline so dependent database targets can explicitly reference write through UseRole, Cephalon.Data.EntityFramework plus Cephalon.Audit.EntityFramework now surface requested versus resolved roles truthfully, and the showcase sample now demonstrates explicit Outbox -> write routing while keeping a dedicated configured HistoryDb role for Docker-backed relational bootstrap
  • Sprint 31 follow-through: ENG-066 is now shipped on top of the same topology baseline so the engine now exposes IDatabaseRoleCatalog, /engine/database-roles, /engine/database-roles/{databaseRoleId}, and snapshot.DatabaseRoles with requested versus resolved role truth, role-consumer metadata, co-location answers, and audit-history enrichment
  • Sprint 38 follow-through: ENG-086 is now shipped on top of the same database-topology baseline so the engine-owned runtime contract now includes RoleProbeFreshnessSeconds, Cephalon.Data.EntityFramework now caches role-probe results with explicit live-versus-cache metadata plus migration-state invalidation, and the showcase sample now surfaces probe source, age, and freshness timing directly from the engine-owned role catalog
  • Sprint 38 follow-through: ENG-087 is now shipped on top of the same database-topology baseline so the engine-owned role contract now exposes the typed DatabaseRoleProbeDescriptor surface and the showcase sample now consumes that typed probe answer directly instead of parsing stable metadata keys locally
  • Sprint 38 follow-through: ENG-088 is now shipped on top of the same database-topology baseline so the engine now publishes /engine/database-topology plus snapshot.DatabaseTopology as the canonical operator posture summary, advisory, and ordered action-plan answer, and the showcase sample now consumes that engine-owned answer for readiness and core insights while keeping read-model drift/backlog follow-through sample-specific
  • Sprint 38 follow-through: ENG-089 is now shipped on top of the same database-topology baseline so the showcase sample now consumes the engine-owned action-plan contract directly, preserves stable action categories plus source role and migration ids in its operator projection/UI/brief, and the docs plus package-surface coverage now describe that shipped contract truthfully
  • Sprint 38 follow-through: ENG-090 is now shipped on top of the same database-topology baseline so the engine now publishes /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook as the canonical ordered migration answer, and the showcase sample now consumes that engine-owned playbook directly while keeping repo-root command adaptation and read-model follow-through sample-specific
  • Sprint 38 follow-through: ENG-091 is now shipped on top of the same database-topology baseline so the engine now publishes stable physical-target identity through /engine/database-roles plus coordination counts, per-step partner targets, and shared-target warning/action guidance through /engine/database-migration-playbook and /engine/database-topology, and the showcase sample now consumes that engine-owned shared-database truth directly in /showcase, the operator brief, and the handoff package
  • Sprint 38 follow-through: ENG-092 is now shipped on top of the same database-topology baseline so the engine-owned migration playbook now groups logical targets into physical-target execution batches with aggregate status, coverage counts, grouped migration ids, and shared-target coordination hints, and the showcase sample now consumes that engine-owned grouped answer directly in /showcase, the operator brief, and the handoff package
  • Sprint 38 follow-through: ENG-093 is now shipped on top of the same database-topology baseline so the engine-owned migration playbook now also publishes grouped production and manual command sets per physical-target execution batch, and the showcase sample now consumes that engine-owned grouped command answer directly in /showcase, the operator brief, and the handoff package
  • Sprint 38 follow-through: ENG-094 is now shipped on top of the same database-topology baseline so the engine-owned migration playbook now also publishes combined production and manual command-batch templates per physical-target execution batch, and the showcase sample now consumes that engine-owned combined batch answer directly in /showcase, the operator brief, and the handoff package
  • Sprint 38 follow-through: ENG-095 is now shipped as the first phase 12 taxonomy slice so BuiltInPatterns now includes strangler-fig plus backend-for-frontend, configuration and /engine/patterns can express those architecture choices directly, and the remaining router/client-binding runtime follow-through stays planned
  • Sprint 38 follow-through: ENG-096 is now shipped as the first non-taxonomy strangler-fig slice so modules and hosts can contribute migration routes through host-agnostic route-contribution and router contracts, /engine/strangler-fig plus snapshot.StranglerFigRoutes now expose the live catalog, and /engine/strangler-fig/resolve can evaluate request ownership while migration progress/config and host-level cutover behavior remain planned
  • Sprint 39: ENG-097 is now shipped as the framework-readiness baseline so scripts/validate-dotnet-readiness.ps1 now records current-versus-readiness SDK selection, target-framework audit results, and deployment-mode claim status, validate-release.ps1 now uses the split test projects plus emits readiness artifacts, the release-validation workflow now also proves a dedicated .NET 11 lane, and scaffolding now keeps net11.0 Dockerfile base images aligned with the requested target framework instead of freezing on 10.0
  • Sprint 39 follow-through: ENG-210 now hardens that same framework-readiness baseline with a machine-readable deployment-mode support contract so scripts/deployment-mode-support.json carries the current trim / Native AOT / single-file support statement, scripts/validate-dotnet-readiness.ps1 now validates project-detected claim status against that manifest, and docs plus package-publishing guidance now stay aligned with the same manifest-backed support story instead of relying on prose-only warnings
  • Sprint 39 follow-through: ENG-211 now carries that same framework-readiness truth into Cephalon.Cli so cephalon doctor reads the packaged deployment-mode support contract, echoes the stable net10.0 shipping floor plus the .NET 11 assessment-only readiness lane, and keeps trim / Native AOT / single-file not-claimed posture visible from the same first-run command path external adopters already use for SDK/runtime/bootstrap verification
  • Sprint 39 follow-through: ENG-212 now carries that same support-contract truth into generated-app doctor validation so cephalon doctor --app-root <path> compares the generated host target framework against the stable net10.0 shipping floor plus the .NET 11 assessment-only readiness lane, reads effective PublishTrimmed, PublishAot, and PublishSingleFile settings from the generated host project plus CephalonFolder.pubxml, and keeps generated-app support posture visible before restore, publish, or deployment work begins
  • Sprint 39 follow-through: ENG-213 now carries that same generated-app doctor truth into deployment assets so cephalon doctor --app-root <path> validates the generated Dockerfile plus the shipped container-image, Azure Container Apps, and Kubernetes deployment assets, compares Dockerfile SDK and ASP.NET base-image tags against the generated host target framework baseline, and keeps stable-floor versus readiness-lane deployment-asset posture visible before container-image or hosted-container deployment work begins
  • Sprint 39 follow-through: ENG-214 now carries that same generated-app doctor truth into published-output deployment baselines so cephalon doctor --app-root <path> validates the shipped Windows Service, IIS, Azure App Service, and Linux systemd deployment assets, checks that those generated scripts and units still align with the current host identity, and keeps self-hosted and hosted deployment-asset posture visible before published-output deployment work begins
  • Sprint 39 follow-through: ENG-215 now carries that same generated-app doctor truth into local orchestration assets so cephalon doctor --app-root <path> validates the shipped compose.yaml and otel-collector-config.yaml assets, compares the generated compose baseline against the shipped Dockerfile plus OTLP collector handoff, compares the generated collector config against health_check, otlp/http on 4318, and the debug-exporter pipelines, and keeps local docker compose up --build posture visible before adopters rely on that local container-runtime path
  • Sprint 39 follow-through: ENG-216 now carries that same generated-app doctor truth into documentation-surface config so cephalon doctor --app-root <path> validates the generated Configurations/AddOpenApi.json and Configurations/AddReferenceDocs.json assets, checks that the OpenAPI title plus hosted reference-doc enablement, route, directory, and default-document settings stay explicit, and keeps /scalar plus optional hosted reference-doc posture visible before adopters rely on those docs surfaces
  • Sprint 39 follow-through: ENG-217 now carries that same generated-app doctor truth into split project configuration baselines so cephalon doctor --app-root <path> validates the generated Configurations/AddEngine.*.json assets plus Configurations/Observability/Development.json, checks that app-model, engine-feature, observability, localization, and development Serilog defaults stay explicit, and keeps split-config runtime plus docs plus telemetry posture visible before adopters rely on those generated defaults
  • Sprint 39 follow-through: ENG-218 now carries that same generated-app doctor truth into host bootstrap alignment so cephalon doctor --app-root <path> validates the scaffolded Program.cs bootstrap source plus the generated host-project PackageReference set and Configurations/**/*.json copy/publish baseline, checks that explicit AddCephalonProjectConfigurations and MapCephalon wiring still stay visible, and keeps startup plus build/publish bootstrap posture visible before adopters rely on edited host startup
  • Sprint 39 follow-through: ENG-219 now carries that same generated-app doctor truth into starter test-harness alignment so cephalon doctor --app-root <path> validates the generated test project plus scaffolded Architecture/CompositionSmokeTests.cs and Features/*BehaviorSpecifications.cs placeholders, checks that composition smoke and Given/When/Then starter seams still stay visible, and keeps starter-test posture visible before adopters replace those files with real specs
  • Sprint 39 follow-through: ENG-220 now carries that same generated-app doctor truth into generated guidance docs so cephalon doctor --app-root <path> validates the scaffolded root README.md, Configurations/README.md, and deploy/*/README.md files, checks that package-source, split-config, publish, deployment, and local-orchestration instructions still align with the current app root, and keeps human-facing run/publish/deploy guidance visible before adopters follow the shipped docs literally
  • Sprint 39 follow-through: ENG-221 now carries that same generated-app doctor truth into local package-feed guidance so cephalon doctor --app-root <path> validates the scaffolded .cephalon/packages/README.md, checks that local package-feed seeding plus shared-feed replacement instructions still align with the current generated app root, and keeps package-bootstrap guidance visible before adopters seed packages or swap NuGet.config
  • Sprint 39 follow-through: ENG-222 now carries that same generated-app doctor truth into executable container deployment scripts so cephalon doctor --app-root <path> validates the scaffolded deploy/container-image/publish-image.ps1, deploy/azure-container-apps/deploy-up.ps1, and deploy/kubernetes/apply.ps1 files, checks that Dockerfile, NuGet.config, host-project/source-root, image placeholder, namespace, and manifest-root seams still align with the current generated app root, and keeps container image plus hosted-container script posture visible before adopters run those shipped deployment scripts
  • Sprint 39 follow-through: ENG-223 now carries that same generated-app doctor truth into Kubernetes manifest content so cephalon doctor --app-root <path> validates the scaffolded deploy/kubernetes/kustomization.yaml, deploy/kubernetes/namespace.yaml, deploy/kubernetes/deployment.yaml, and deploy/kubernetes/service.yaml files, checks that namespace, labels, image placeholder, env, probe, and ClusterIP service seams still align with the current generated app root, and keeps platform-neutral Kubernetes manifest posture visible before adopters rely on those shipped manifests literally
  • Sprint 39 follow-through: ENG-224 now carries that same generated-app doctor truth into teardown and service-manager environment assets so cephalon doctor --app-root <path> validates the scaffolded deploy/windows-service/remove-service.ps1, deploy/iis/remove-site.ps1, and deploy/linux/systemd/<App>.env files, checks that Windows Service stop/delete, IIS site/app-pool teardown, and Linux systemd environment plus telemetry override seams still align with the current generated app root, and keeps teardown plus environment posture visible before adopters rely on those shipped operational assets
  • Sprint 39 follow-through: ENG-098 now extends the same phase 11 resilience surface with shared behavior-execution rate limiting in Cephalon.Behaviors, truthful /engine/behavior-resilience plus snapshot metadata for that execution layer, and route-truthful REST 429 answers that can intentionally surface either the host-owned or behavior-owned limiter through Engine:Resilience:RateLimiting:Overrides
  • Sprint 39 follow-through: ENG-099 now carries that same behavior-execution rate-limiting truth across the generic behavior HTTP adapters so GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings all emit protocol-native limiter envelopes instead of flattening shared dispatch rejections into generic transport failures
  • Sprint 40 follow-through: ENG-100 now carries the remaining behavior-execution timeout and circuit-breaker truth across the generic behavior HTTP adapters so GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings emit protocol-native timeout and open-circuit envelopes instead of flattening those shared dispatch rejections into generic transport failures
  • Sprint 40 follow-through: ENG-101 now extends the phase 12 strangler-fig baseline with deterministic Engine:Migration:StranglerFig default plus per-route policy overlays, a new host-agnostic migration-policy catalog projected into snapshot.StranglerFigRoutePolicies, and ASP.NET Core /engine/strangler-fig/runtime operator routes
  • Sprint 40 follow-through: ENG-102 now closes the first ASP.NET Core strangler-fig cutover loop so Engine:Migration:StranglerFig:AspNetCore can rewrite rooted local targets, redirect or proxy absolute HTTP or HTTPS targets, expose /engine/strangler-fig/cutover plus /engine/strangler-fig/cutover/resolve, and fail unsupported selected endpoints truthfully with 502 without breaking the shared migration runtime truth
  • Sprint 40 follow-through: ENG-119 now ships the engine-first strangler-fig ingress follow-through so Cephalon.Abstractions exposes IStranglerFigIngressRuntimeCatalog plus StranglerFigIngressRuntimeDescriptor, Cephalon.Engine projects snapshot.StranglerFigIngressRoutes, and ASP.NET Core exposes /engine/strangler-fig/ingress* while cutover now derives from the shared ingress truth and provider-specific ingress or edge automation remains later
  • Sprint 40 follow-through: ENG-103 now ships the first backend-for-frontend client-binding runtime so modules, hosts, and Engine:BackendForFrontend:Bindings can contribute per-client transport bindings through host-agnostic contracts, snapshot.BackendForFrontendBindings plus ASP.NET Core /engine/backend-for-frontend routes publish the merged runtime truth, and the backend-for-frontend pattern now auto-selects when bindings exist
  • Sprint 40 follow-through: ENG-104 now adds the first client-aware backend-for-frontend REST filtering runtime so ASP.NET Core derives IBackendForFrontendRestRuntimeCatalog, snapshot.BackendForFrontendRestEndpoints, and /engine/backend-for-frontend/rest-endpoints from the shared binding catalog plus published REST endpoint truth while per-client OpenAPI/Scalar materialization remains later
  • Sprint 40 follow-through: ENG-105 now closes the first backend-for-frontend REST documentation/materialization loop so ASP.NET Core derives IBackendForFrontendRestDocumentRuntimeCatalog, snapshot.BackendForFrontendRestDocuments, /engine/backend-for-frontend/rest-documents, and scope-specific filtered OpenAPI plus Scalar surfaces from the shared BFF REST runtime truth and the normal host OpenApi:* configuration
  • Sprint 40 follow-through: ENG-106 now ships the first feature-flag runtime baseline so hosts, configuration, and modules can contribute FeatureFlagDescriptor entries through engine.AddFeatureFlag(...), Engine:Features, and IFeatureFlagContributor, the engine now projects merged truth through IFeatureFlagRuntimeCatalog, IFeatureToggle, and snapshot.FeatureFlags, and ASP.NET Core now exposes /engine/features plus evaluation routes while the later generic provider bridge and any future capability publication remain separate follow-through
  • Sprint 40 follow-through: ENG-107 now ships the generic external-provider bridge baseline for feature flags so FeatureFlagDescriptor.ProviderBindings, Engine:Features:Flags:*:ProviderBindings, engine.AddFeatureFlagProvider(...), and IFeatureFlagProvider can add provider-backed rollout gates without replacing the Cephalon-owned runtime catalog, /engine/features/{featureFlagId}/evaluate now returns provider-result details, and behavior-owned HTTP execution now keeps subject propagation aligned with the same provider-backed truth
  • Sprint 40 follow-through: ENG-108 now ships the first host-agnostic saga choreography baseline so IBehaviorTopologyBuilder.AsSagaChoreography() plus source-generated topology literals can declare saga-choreography, Cephalon.Behaviors.Patterns now exposes ISagaChoreographyPublisher, SagaChoreographyPublication, SagaChoreographyStepResult, InMemorySagaChoreographyPublisher, and ChoreographySagaExecutionStrategy, and Cephalon.Behaviors now reports capability behaviors.saga-choreography plus advisory ABT-005 when choreography steps omit outbox staging
  • Sprint 40 follow-through: ENG-109 now ships the first durable-execution baseline so IBehaviorTopologyBuilder.AsDurableExecution() plus source-generated topology literals can declare durable-execution, Cephalon.Behaviors.Patterns now exposes IDurableExecution<TState>, IDurableExecution<TInput, TState, TOutput>, DurableExecutionState<TState>, DurableExecutionStepResult<TOutput>, and DurableExecutionStrategy, Cephalon.Behaviors now reports capability behaviors.durable-execution plus rule ABT-006, and Kafka/RabbitMQ/test behavior contexts now flow IEventStore into the shared pipeline while richer durable runtime/operator surfaces remain later follow-through
  • Sprint 40 follow-through: ENG-110 now ships the explicit saga choreography eventing bridge so Cephalon.Eventing.Behaviors exposes AddBehaviorEventingBridge(), preserves explicit ISagaChoreographyPublisher overrides, stages choreography publications through the same outbox-backed eventing publish path used by Cephalon.Eventing, and projects capability eventing.behaviors.saga-choreography plus the saga-choreography-bridges runtime surface without moving choreography ownership into the eventing baseline
  • Sprint 40 follow-through: ENG-111 now ships the first durable-execution runtime/operator catalog so Cephalon.Abstractions exposes DurableExecutionRuntimeDescriptor plus IDurableExecutionRuntimeCatalog, Cephalon.Behaviors.Patterns derives the catalog from shared durable behavior topology plus registered implementation types, snapshot.DurableExecutions now publishes the same answer, and ASP.NET Core now exposes /engine/durable-executions plus id/module/transport drill-down routes while replay-progress and failure-posture follow-through remain later
  • Sprint 40 follow-through: ENG-112 now ships the first durable-execution live runtime state and failure-posture surface so Cephalon.Abstractions exposes DurableExecutionRuntimeState plus IDurableExecutionRuntimeStateCatalog, Cephalon.Behaviors.Patterns reports per-stream durable observations directly from DurableExecutionStrategy, snapshot.DurableExecutionStates now publishes the same answer, and ASP.NET Core now exposes /engine/durable-executions/runtime plus stream/behavior/module/transport drill-down routes while timers, signals, and compensation helpers remain later
  • Sprint 40 follow-through: ENG-113 now ships the first durable timer/signal coordination surface so Cephalon.Abstractions exposes DurableExecutionPendingTimer plus DurableExecutionPendingSignal, DurableExecutionStepResult<TOutput> and DurableExecutionRuntimeState can carry pending timers/signals without a second workflow registry, the shared durable strategy now emits a truthful waiting posture with 202 when coordination remains pending, and ASP.NET Core now exposes /engine/durable-executions/runtime/timers* plus /engine/durable-executions/runtime/signals* while compensation helpers remain later
  • Sprint 40 follow-through: ENG-114 now ships the first durable compensation-helper surface so Cephalon.Abstractions exposes DurableExecutionCompensationAction, DurableExecutionStepResult<TOutput> and DurableExecutionRuntimeState can carry operator-facing compensation actions without changing durable coordination semantics, the shared runtime-state catalog now preserves and filters those helpers without a second workflow registry, and ASP.NET Core now exposes /engine/durable-executions/runtime/compensations* while any future auto-executing recovery remains later
  • Sprint 40 follow-through: ENG-115 now ships the first saga choreography authoring-helper surface so Cephalon.Behaviors.Patterns exposes ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, SagaChoreographyStepResult<TOutput>, and typed JSON publication helpers on SagaChoreographyPublication, while ChoreographySagaExecutionStrategy continues to normalize the shared choreography result contract without inventing a second registry or collapsing the explicit eventing bridge into the patterns baseline
  • Sprint 40 follow-through: ENG-116 now ships the first saga choreography runtime/operator catalog so Cephalon.Abstractions exposes SagaChoreographyRuntimeDescriptor plus ISagaChoreographyRuntimeCatalog, Cephalon.Behaviors.Patterns derives the catalog from shared choreography behavior topology plus registered implementation types, snapshot.SagaChoreographies now publishes the same answer, and ASP.NET Core now exposes /engine/saga-choreographies plus id/module/transport drill-down routes. Live publication-state and capability-publication follow-through landed later and are now shipped
  • Sprint 40 follow-through: ENG-117 now ships the first live saga choreography publication-state baseline so Cephalon.Abstractions exposes SagaChoreographyPublicationRuntimeState plus ISagaChoreographyPublicationRuntimeStateCatalog, ChoreographySagaExecutionStrategy reports accepted and failed publication handoff observations directly from the shared choreography path, snapshot.SagaChoreographyPublicationStates now publishes the same answer, and ASP.NET Core now exposes /engine/saga-choreographies/runtime plus publication, behavior, module, transport, channel, correlation, compensation, and failure drill-down routes; the module-backed capability-publication follow-through is now also shipped through behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state
  • Sprint 40 follow-through: ENG-118 now ships the module-backed saga choreography capability-publication follow-through so Cephalon.Behaviors publishes behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state only when AddBehaviorPatterns() actually registers ISagaChoreographyRuntimeCatalog and ISagaChoreographyPublicationRuntimeStateCatalog, /engine/capabilities now exposes the same pack/service/snapshot/route truth, and capability provenance stays with the behaviors module instead of inventing a synthetic engine or bridge source
  • Sprint 36–37 (Phase 11): ENG-076 now ships the contract-first resilience baseline — Engine:Resilience, AppProfile.Resilience, /engine/resilience, and the missing onion-architecture plus anti-corruption-layer pattern descriptors — ENG-077 now ships the first transport-native follow-through through ASP.NET Core public-HTTP rate limiting plus /engine/rate-limiting, ENG-078 now adds endpoint-scoped behavior/transport override modeling for ASP.NET Core HTTP surfaces, ENG-079 now adds the first behavior-pipeline follow-through through shared timeout-plus-bulkhead enforcement plus /engine/behavior-resilience, ENG-080 now adds behavior-execution override resolution with behavior/transport precedence plus route-truthful REST/OpenAPI answers, ENG-081 now adds shared circuit-breaker enforcement plus live runtime state and truthful REST 503 answers for open circuits, ENG-082 now adds behavior-authored idempotency plus retry-eligibility classification/runtime metadata for the same behavior-execution surface, ENG-083 now closes the loop with idempotency-gated retry execution plus truthful retry runtime metadata in the shared behavior pipeline, ENG-084 now splits the built-in ASP.NET Core GraphQL surface into explicit HTTP, schema, SSE, and WebSocket routes while /engine/rate-limiting now publishes truthful long-lived stream/connection metadata, ENG-085 now rounds out the shared GraphQL authoring baseline through ConfigureGraphQLMutation(...) plus ConfigureGraphQLSubscription(...) and protocol-level proof that configured schema, SSE, and WebSocket routes execute real SDL, text/event-stream, and graphql-transport-ws behavior, ENG-098 now extends the shared behavior-execution surface with rate limiting plus REST 429 precedence that stays truthful when ASP.NET Core and behavior-dispatch limiters both target the same route, ENG-099 now keeps that same rate-limiting truth protocol-native for the generic behavior HTTP GraphQL, JSON-RPC, SSE, and WebSocket adapters, and ENG-100 now keeps timeout plus open-circuit 503 truth equally protocol-native for those same generic behavior HTTP adapters; broader non-REST resilience-envelope semantics beyond the current 429/503 baseline remain planned follow-through
  • Sprint 38–40 (Phase 12): planned migration and advanced coordination — the descriptor baseline for strangler fig plus BFF, the first strangler-fig runtime-contract slice, the first configuration-driven strangler-fig migration-policy/progress slice, the first ASP.NET Core host-level cutover runtime, the engine-first strangler-fig ingress-runtime follow-through, the first BFF client-binding runtime, the first client-aware BFF REST filtering runtime, the first BFF REST documentation/materialization runtime, the first feature-flag runtime baseline, the generic external-provider bridge baseline, the first host-agnostic saga choreography baseline, the explicit choreography-to-eventing bridge baseline, the first saga choreography authoring-helper follow-through, the first saga choreography runtime/operator catalog follow-through, the first live saga choreography publication-state follow-through, the module-backed saga choreography capability-publication follow-through, the first durable-execution baseline, the first durable runtime/operator catalog follow-through, the first durable live-state/failure-posture follow-through, the first durable timer/signal coordination follow-through, and the first durable compensation-helper follow-through are now shipped, while broader non-REST frontend-materialization, provider-specific ingress or edge automation, and provider-specific feature-flag companion packs remain planned
  • Sprint 40–41 (Phase 13): ENG-120 now ships the first cell-based architecture boundary baseline through CellBoundaryDescriptor, ICellBoundaryCatalog, /engine/cells, snapshot.CellBoundaries, and the cell-boundaries technology surface, ENG-121 now adds the first governed cell-route baseline through CellRouteDescriptor, ICellRouteCatalog, /engine/cell-routes, snapshot.CellRoutes, and the cell-routes technology surface, ENG-122 now adds the first cell health-isolation baseline through CellHealthIsolationDescriptor, ICellHealthIsolationCatalog, /engine/cell-health-isolations, snapshot.CellHealthIsolations, and the cell-health-isolations technology surface, ENG-123 now closes the engine-owned cell baseline with configuration-driven traffic automation through Engine:Cells:TrafficAutomation, ICellTrafficAutomationRuntimeCatalog, /engine/cell-traffic-automations, snapshot.CellTrafficAutomations, and the cell-traffic-automations technology surface, ENG-124 now adds the first data-mesh runtime baseline through /engine/data-products plus snapshot.DataProducts, ENG-125 now adds the first CDC capture descriptor baseline through /engine/cdc-captures plus snapshot.CdcCaptures, ENG-126 now adds the first live CDC runtime-state follow-through through CdcCaptureRuntimeState, ICdcCaptureRuntimeStateCatalog, /engine/cdc-captures/runtime, snapshot.CdcCaptureStates, and optional linked outbox dispatch posture, ENG-127 now extends that same surface with typed CDC freshness, lag, and publication-posture answers, ENG-128 now adds the shared CDC hosted-execution substrate through CdcCaptureExecutionResult, data.cdc.execution, data-cdc-capture-flow, data-cdc-capture-pump, and shared in-process outbox staging/runtime-story truth, ENG-129 now closes the shared replay-safe checkpoint-commit follow-through through CdcCaptureExecutionAcknowledgement, ICdcCaptureAcknowledger, acknowledge-cdc-progress, and post-stage provider acknowledgement metadata, ENG-130 now adds the execution-topology layer through CdcCaptureExecutionRuntimeDescriptor, ICdcCaptureExecutionRuntimeCatalog, /engine/cdc-capture-runtimes, and snapshot.CdcCaptureExecutionRuntimes, ENG-131 now binds capture-side authored/requested/effective execution ownership through CdcCaptureExecutionBindingDescriptor, ExecutionBinding on /engine/cdc-captures* plus /engine/cdc-captures/runtime*, deterministic runtime-claim resolution, inverse execution-runtime drill-down routes, and shared-pump filtering so shared or future provider-native runners stay on one truthful ownership model, ENG-132 now lets hosts declare external-managed or provider-native CDC execution runtimes through first-class runtime fields plus DataRuntimeOptions.CdcExecutionRuntimes while keeping /engine/cdc-capture-runtimes*, inverse capture/runtime drill-down routes, and the shared-pump ownership truth aligned on one registry, ENG-133 now proves the first concrete provider-native runner through MongoDB change streams on the same /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces, ENG-134 now adds the first opt-in out-of-process CDC live-reporting seam through CdcCaptureRuntimeObservation, ICdcCaptureExecutionRuntimeReportSink, and POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports so external runners can refresh the same runtime-state and execution-runtime summaries without a second registry, ENG-135 now extends the shared cell automation catalog with first-class providerId plus edgeNodeIds, provider and edge-node drill-down routes, and derived provider-managed / edge-managed / provider-and-edge-managed posture so provider-aware and edge-aware traffic automation stay on one runtime truth, ENG-136 now adds the first provider-managed traffic materializer seam on that same catalog, ENG-137 now lets Cephalon.Edge contribute the first edge-runtime traffic materializer through ICellTrafficAutomationEdgeMaterializer, generic materialization result/state contracts, and additive edge-materialization fields on CellTrafficAutomationRuntimeDescriptor, ENG-139 now proves the first provider-specific control-plane materializer through Cephalon.Edge.KubernetesGateway, AddKubernetesGatewayTrafficMaterializer(...), deterministic Gateway API intent projection, and the kubernetes-gateway-traffic-materializations technology surface while keeping materializer selection plus reconciliation truth on the shared /engine/cell-traffic-automations* and snapshot.CellTrafficAutomations surfaces, ENG-140 now adds the first live Kubernetes Gateway API observation overlay through ICellTrafficAutomationMaterializationReportSink, KubernetesGatewayTrafficObservationOptions, opt-in observe-only materializer mode, and recurring Gateway plus HTTPRoute status polling so the same shared automation catalog, provider-specific technology surface, and snapshot.CellTrafficAutomations can publish observed Accepted/ResolvedRefs/Programmed, drift, and freshness posture without inventing a second control-plane registry, ENG-141 now hardens that same provider-specific pack with apply-and-reconcile mode so configured-intent remains truthfully pending, owned HTTPRoute resources can be created or replaced, Gateway stays a pre-provisioned dependency, and the same shared automation catalog plus provider-specific technology surface can publish ownership-aware write results together with observed control-plane status without inventing a second registry, ENG-142 now proves that the same provider-materializer seam also fits Traefik through Cephalon.Edge.Traefik, AddTraefikTrafficMaterializer(...), deterministic IngressRoute intent projection, and the traefik-ingressroute-traffic-materializations technology surface while keeping materializer selection plus reconciliation truth on the shared /engine/cell-traffic-automations* and snapshot.CellTrafficAutomations surfaces, ENG-143 now normalizes shared ownership/dependency/drift/lifecycle-action truth across provider and edge materializers, ENG-144 now adds the first live Traefik observation overlay through TraefikTrafficObservationModes, TraefikTrafficObservationOptions, opt-in observe-only polling, and recurring Traefik CRD plus dependent Kubernetes resource observation so the same shared automation catalog, provider-specific technology surface, and snapshot.CellTrafficAutomations can publish observed route existence, ownership, dependency, drift, and freshness posture without inventing a second control-plane registry, ENG-145 now hardens that same Traefik pack with owned IngressRoute apply-and-reconcile so the same shared automation catalog and provider-specific technology surface can publish ownership-aware write metadata together with reconciled live Traefik observation without inventing a second registry, ENG-146 now hardens provider-native lifecycle execution across Kubernetes Gateway and Traefik by distinguishing external conflicts from orphaned transfer candidates, lazily resolving active owners through the shared traffic catalog, and preserving merged create/replace/transfer lifecycle truth on the existing shared and provider-specific surfaces, ENG-147 now closes the first cleanup-sweep follow-through through opt-in EnableCleanupSweep, namespace-scoped delete/prune passes over stale transferred or orphaned provider-owned routes, and additive providerMaterialization.cleanup* plus provider-surface cleanup metadata on that same runtime story, and ENG-150 now adds richer provider-native condition semantics through CellTrafficAutomationMaterializationConditionDescriptor, stable condition dimensions/categories/states/severities, typed Conditions on provider and edge materialization results, MaterializationConditions on CellTrafficAutomationRuntimeDescriptor, and additive materialization.*, providerMaterialization.*, plus edgeMaterialization.* condition summaries such as conditionCount, conditionCategories, conditionBreakdown, and highestConditionSeverity; broader dependency-aware teardown and additional CDC execution topologies remain planned
  • Sprint 40–41 (Phase 13): ENG-148 now adds the second provider-native CDC runner and first relational CDC proof through Cephalon.Data.SqlServer, AddSqlServerData(...), SqlServerCdcCaptureOptions, sqlserver-cdc-capture-flow, sqlserver-cdc-capture-pump, durable startLsn|seqval|operation checkpoints, and the same shared /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces without inventing a second relational CDC registry, while ENG-149 now hardens external CDC reporting on that same runtime story with stable ReportId, configured stale-window plus out-of-order policy, and aggregate ObservationFreshness on the existing /engine/cdc-* plus snapshot surfaces
  • Sprint 40–41 (Phase 13): ENG-152 now deepens that same shared external CDC runtime story with first-class ReporterId plus EdgeNodeId, declared ReporterLeaseSeconds, RejectConflictingReporterIds, and EdgeNodeIds, shared reporter-lease and edge-node validation on the external report sink, and additive LastReporterId, ActiveReporterId, ReporterLeaseExpiresAtUtc, ObservedEdgeNodeIds, plus LastEdgeNodeId answers on the existing /engine/cdc-* and snapshot surfaces instead of a second topology coordinator
  • Sprint 40–41 (Phase 13): ENG-153 now adds the third provider-native CDC runner and the first logical-replication streaming proof through Cephalon.Data.Postgres, AddPostgresData(...), PostgresLogicalReplicationCaptureOptions, postgresql-logical-replication-capture-flow, postgresql-logical-replication-capture-pump, slot-backed durable slotName|commitLsn|transactionEndLsn checkpoints, publication/table validation, optional slot creation, and the same shared /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces without inventing a PostgreSQL-specific CDC registry
  • Sprint 40–41 (Phase 13): ENG-154 now hardens that PostgreSQL runner with publication and slot lifecycle truth through RecreateSlotIfInvalidated, slot type/plugin/database ownership validation, inactive invalidated-slot recreation, restart-safe slot-confirmed-flush-lsn resume metadata, and additive slotLifecycle* plus failure-kind answers on the existing shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces instead of a PostgreSQL-only watchdog
  • Sprint 40–41 (Phase 13): ENG-155 now adds richer external and edge-aware CDC failover plus takeover truth on that same shared runtime story: CdcCaptureRuntimeState plus CdcCaptureExecutionRuntimeSummary now publish typed ReporterCoordination, Cephalon.Data now records rejected conflicting reporters and accepted post-expiry takeovers on the shared runtime-state catalog, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, and snapshot surfaces now answer active-owner versus expired-lease versus conflicted reporter posture without inventing a second topology coordinator
  • Sprint 40–41 (Phase 13): ENG-156 now hardens that same shared external CDC runtime story with richer multi-reporter reconciliation: Cephalon.Abstractions now ships CdcCaptureReporterParticipantRoles plus CdcCaptureReporterParticipantStatus, CdcCaptureReporterCoordinationStatus now carries ReporterParticipants, HasStandbyReporters, and HasRejectedReporters, and Cephalon.Data now keeps accepted previous owners visible as standby participants plus rejected conflicts visible as rejected participants on the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, and snapshot surfaces instead of inventing a second coordination registry
  • Sprint 40–41 (Phase 13): ENG-157 now hardens that same shared external CDC runtime story with stable takeover and degraded-posture semantics: Cephalon.Abstractions now ships CdcCaptureReporterCoordinationIssueReasons plus CdcCaptureReporterTakeoverStates, CdcCaptureReporterCoordinationStatus now carries TakeoverState, DegradedReason, RequiresTakeover, and HasCompletedTakeover, and Cephalon.Data now classifies awaiting-takeover, rejected-conflict, and multiple-active ambiguity on the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, and snapshot surfaces without inventing a second operator taxonomy
  • Sprint 40–41 (Phase 13): ENG-158 now adds the fourth provider-native CDC runner and the first MySQL binlog proof through Cephalon.Data.MySql, AddMySqlData(...), MySqlBinlogCaptureOptions, mysql-binlog-capture-flow, mysql-binlog-capture-pump, durable binlogFile|position checkpoints, bounded row-event batching, and the same shared /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces without inventing a MySQL-specific CDC registry
  • Sprint 40–41 (Phase 13): ENG-159 now hardens that same MySQL provider-native runner with source-server identity plus retained-binlog lifecycle truth: MySqlBinlogCaptureOptions now supports ExpectedSourceServerUuid, the Cephalon-managed checkpoint table now keeps additive SourceServerUuid, SourceServerId, GtidExecutedSet, BinlogFormat, and BinlogRowImage metadata, and the existing shared /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces now publish binlogLifecycle*, sourceServerIdentity*, checkpoint*, and GTID observe-only answers without inventing a MySQL-only lifecycle registry
  • Sprint 40–41 (Phase 13): ENG-160 now broadens the shared external CDC runtime story with reporter rejoin and stale-conflict cleanup, while ENG-161 now adds the fifth provider-native CDC implementation and first Oracle LogMiner redo-log proof through Cephalon.Data.Oracle, AddOracleData(...), OracleLogMinerCaptureOptions, oracle-logminer-capture-flow, oracle-logminer-capture-pump, durable commitScn|changeScn|rsId|ssn checkpoints, bounded SCN-window LogMiner execution, and the same shared /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces without inventing an Oracle-specific CDC registry
  • Sprint 40–41 (Phase 13): ENG-162 now hardens that Oracle runner with additive database-identity plus archive-log lifecycle and checkpoint-provenance truth, while ENG-163 now adds reporter-, edge-, coordination-, and degraded-reason drill-downs on the same shared /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces so operator flows can query one reporter or one degraded posture without inventing a second coordination surface
  • Sprint 40–41 (Phase 13): ENG-164 now adds the first external managed-connector capture implementation through Cephalon.Data.Debezium, AddDebeziumData(...), DebeziumConnectorOptions, and DebeziumCaptureOptions, projecting Debezium-managed capture ownership plus external runtime reporting onto the same shared /engine/cdc-*, /engine/runtime-story, and snapshot surfaces without faking a hosted execution, execution graph, or Debezium-only registry
  • Sprint 40–41 (Phase 13): ENG-165 now hardens that same Debezium managed-connector story with observe-only lifecycle and task-reconciliation truth through ManagementMode, ExpectedTaskCount, normalized debezium* report metadata, and runtime-scoped execution-runtime metadata promotion on the same shared /engine/cdc-*, /engine/runtime-story, and snapshot surfaces without inventing a Debezium-only lifecycle registry
  • Sprint 40–41 (Phase 13): ENG-166 now adds richer CDC operator-story rollups on that same shared external runtime story by projecting typed ReporterCoordinationRollup breakdowns, active/standby/rejected reporter ids, and degraded capture ids onto CdcCaptureExecutionRuntimeSummary, the existing /engine/cdc-capture-runtimes* routes, and snapshot.CdcCaptureExecutionRuntimes without inventing a second coordination or Debezium-only rollup surface
  • Sprint 40–41 (Phase 13): ENG-167 now hardens that same shared external runtime story with declared-versus-reported coverage truth through CdcCaptureExecutionRuntimeReportingCoverageStates, CdcCaptureExecutionRuntimeReportingCoverageStatus, additive ReportingCoverage on CdcCaptureExecutionRuntimeSummary, and report-aware ReportedCdcCaptureIds projection on the existing /engine/cdc-capture-runtimes* routes plus snapshot.CdcCaptureExecutionRuntimes without inventing a second coverage registry
  • Sprint 40–41 (Phase 13): ENG-168 now closes the next shared follow-through on that same external runtime story through CdcCaptureExecutionRuntimeRemediationStates, CdcCaptureExecutionRuntimeRemediationCategories, additive Remediation on CdcCaptureExecutionRuntimeSummary, resolved-ownership coverage/remediation derivation in the shared execution-runtime catalog, and runtime-first remediation drill-down routes on the existing /engine/cdc-capture-runtimes* family plus snapshot.CdcCaptureExecutionRuntimes without inventing a second remediation registry
  • Sprint 40–41 (Phase 13): ENG-169 now closes the next shared follow-through on that same external runtime story through managed-connector governance posture on CdcCaptureExecutionRuntimeDescriptor.ManagedConnectorGovernance, merged managedConnector* governance derivation in the shared execution-runtime catalog, and runtime-first /engine/cdc-capture-runtimes/governance/* drill-downs without inventing a Debezium-only governance registry
  • Sprint 40–41 (Phase 13): ENG-170 now closes the next shared follow-through on that same external runtime story through desired-versus-observed managed-connector drift posture on CdcCaptureExecutionRuntimeDescriptor.ManagedConnectorDrift, merged declared-versus-reported managedConnector* drift derivation in the shared execution-runtime catalog, and runtime-first /engine/cdc-capture-runtimes/drift/* drill-downs without inventing a Debezium-only drift registry
  • Sprint 40–41 (Phase 13): ENG-171 now closes the next shared follow-through on that same external runtime story through managed-connector action-planning posture on CdcCaptureExecutionRuntimeDescriptor.ManagedConnectorActionPlan, merged remediation-plus-governance-plus-drift derivation in the shared execution-runtime catalog, and runtime-first /engine/cdc-capture-runtimes/action-plans/* plus /engine/cdc-capture-runtimes/actions/* drill-downs without inventing a Debezium-only action-planning registry
  • Sprint 40–41 (Phase 13): ENG-172 now closes the next shared follow-through on that same external runtime story through managed-connector write-path readiness posture on CdcCaptureExecutionRuntimeDescriptor.ManagedConnectorWritePathReadiness, merged coverage-plus-remediation-plus-governance-plus-drift-plus-action-planning derivation in the shared execution-runtime catalog, and runtime-first /engine/cdc-capture-runtimes/write-path-readiness/* drill-downs without inventing a Debezium-only readiness registry
  • Sprint 40–41 (Phase 13): ENG-150 now adds richer provider-native condition semantics on the shared cell traffic runtime story, while ENG-151 now broadens dependency-aware teardown on that same runtime story by publishing cleanupStrategy plus primary/dependency cleanup breakdowns, keeping Kubernetes Gateway explicitly primary-only for owned HTTPRoute sweeps, and letting Traefik remove safe owned Middleware plus TLSOption dependents on the same shared plus provider-specific surfaces; broader provider-side teardown families and additional CDC execution topologies remain planned
  • Sprint 42: ENG-230 now establishes the engine surface maturity audit baseline so package ownership and proof levels are explicit before more mixed-maturity expansion lands
  • Sprint 43: ENG-231 now adds the first truthful managed event-subscription execution baseline so the eventing family proves one managed execution story before widening descriptor breadth again
  • Sprint 44: shipped ENG-232 agentics tool execution and run-state baseline so Cephalon.Agentics grows from catalog truth into one real dispatcher/run-state loop
  • Sprint 45: shipped ENG-233 retrieval indexing, query execution, and freshness baseline so Cephalon.Retrieval grows from collection catalog truth into one provider-fed lexical index/query/freshness loop
  • Sprint 46: shipped ENG-234 multi-tenancy governance, membership, and domain workflow companion split so Cephalon.MultiTenancy stays focused on tenant resolution while the broader workflow lane is explicit and companion-planned
  • Sprint 47: shipped ENG-235 multi-tenancy governance membership evaluation baseline so Cephalon.MultiTenancy.Governance owns the first concrete membership catalog/evaluation runtime proof without pulling broader governance workflows into the base package
  • Sprint 48: shipped ENG-236 multi-tenancy governance invitation validation baseline so Cephalon.MultiTenancy.Governance owns the first concrete invitation catalog/validation runtime proof without taking over delivery, durable storage, public onboarding, or identity-provider synchronization
  • Sprint 49: shipped ENG-237 multi-tenancy governance domain ownership validation baseline so Cephalon.MultiTenancy.Governance owns declared domain-ownership catalog/validation without taking over DNS/HTTP proof collection, durable storage, public onboarding, or tenant administration
  • Sprint 50: shipped ENG-238 multi-tenancy governance action decision baseline so Cephalon.MultiTenancy.Governance owns approval/remediation action cataloging plus deterministic action decisions while leaving workflow execution to the follow-up now shipped in ENG-239
  • Sprint 51: shipped ENG-239 multi-tenancy governance action workflow execution baseline so Cephalon.MultiTenancy.Governance owns in-process request/approve/reject/remediation/expire status transitions over the same action catalog while leaving durable action storage to the follow-up now shipped in ENG-240
  • Sprint 52: shipped ENG-240 multi-tenancy governance durable action store baseline so Cephalon.MultiTenancy.Governance owns a public action-store seam, in-memory default, opt-in local JSON durability, store-failed workflow outcome, and action-store runtime metadata without taking over broader human-task, notification, remediation-execution, tenant-admin, or provider-backed store ownership
  • Sprint 53: shipped ENG-241 multi-tenancy governance durable membership store baseline so Cephalon.MultiTenancy.Governance owns a public membership-store seam, in-memory default, opt-in local JSON durability, and membership-store runtime metadata without taking over invitation/domain storage, identity-provider sync, tenant-admin, public onboarding, or provider-backed store ownership
  • Sprint 54: shipped ENG-242 multi-tenancy governance durable invitation store baseline so Cephalon.MultiTenancy.Governance owns a public invitation-store seam, in-memory default, opt-in local JSON durability, and invitation-store runtime metadata without taking over invitation delivery, public onboarding, identity-provider sync, tenant-admin, domain storage, or provider-backed store ownership
  • Sprint 55: shipped ENG-243 multi-tenancy governance durable domain ownership store baseline so Cephalon.MultiTenancy.Governance owns a public domain-ownership-store seam, in-memory default, opt-in local JSON durability, and domain-ownership-store runtime metadata without taking over DNS/HTTP proof collection, domain lifecycle automation, tenant-admin, public onboarding, or provider-backed store ownership
  • Sprint 56: shipped ENG-244 multi-tenancy governance domain ownership verification workflow baseline so Cephalon.MultiTenancy.Governance owns in-process request/verify/reject/suspend/expire status transitions over the same domain-ownership catalog and store without taking over DNS/HTTP proof collection, external polling, tenant-admin, public onboarding, or provider-backed verification ownership
  • Sprint 57: shipped ENG-245 multi-tenancy governance domain ownership proof evaluation baseline so Cephalon.MultiTenancy.Governance owns reported-proof comparison plus verify/reject workflow mutation without taking over DNS/HTTP proof collection, external polling, tenant-admin, public onboarding, or provider-backed verification collection
  • Sprint 58: shipped ENG-246 multi-tenancy governance domain ownership proof challenge issuance baseline so Cephalon.MultiTenancy.Governance owns expected-proof challenge generation plus DNS TXT/HTTP publication hints without taking over DNS/HTTP publication, collection, external polling, tenant-admin, public onboarding, or provider-backed verification collection
  • Sprint 59: shipped ENG-247 multi-tenancy governance domain ownership proof publication planning baseline so Cephalon.MultiTenancy.Governance owns deterministic DNS TXT / HTTP file publication instructions and optional plan metadata recording without taking over DNS mutation, HTTP hosting, DNS TXT collection, external polling, tenant-admin, public onboarding, or provider-backed verification collection at that slice boundary; HTTP file proof publication later shipped in ENG-253
  • Sprint 60: shipped ENG-248 multi-tenancy governance domain ownership HTTP proof collection baseline so Cephalon.MultiTenancy.Governance owns bounded on-demand HTTP file proof collection and evaluation while still leaving DNS publication, HTTP publication, DNS TXT collection, external polling, tenant-admin, public onboarding, and provider-backed verification collection outside that slice boundary; HTTP file proof publication later shipped in ENG-253
  • Sprint 61: shipped ENG-249 multi-tenancy governance domain ownership proof verification runner baseline so Cephalon.MultiTenancy.Governance owns one low-glue orchestration entry point across challenge issuance, publication planning, observed-proof evaluation, and optional HTTP file proof collection while still leaving DNS publication, HTTP publication, DNS TXT collection, external polling, tenant-admin, public onboarding, and provider-backed verification collection outside that slice boundary; HTTP file proof publication later shipped in ENG-253
  • Sprint 62: shipped ENG-250 multi-tenancy governance domain ownership DNS TXT proof collection baseline so Cephalon.MultiTenancy.Governance owns configured on-demand DNS TXT proof collection through an explicit DNS-over-HTTPS resolver while still leaving DNS publication, HTTP publication, background polling, tenant-admin, public onboarding, and provider-backed verification mutation outside that slice boundary; background polling scheduling later shipped in ENG-252 and HTTP file proof publication later shipped in ENG-253
  • Sprint 63: shipped ENG-251 multi-tenancy governance domain ownership proof polling runner baseline so Cephalon.MultiTenancy.Governance owns a bounded on-demand loop that selects pending or rejected HTTP/DNS declarations and delegates each attempt to the verification runner while still leaving DNS publication, HTTP publication, tenant-admin, public onboarding, and provider-backed mutation outside that slice boundary; automatic background scheduling later shipped in ENG-252 and HTTP file proof publication later shipped in ENG-253
  • Sprint 64: shipped ENG-252 multi-tenancy governance automatic background proof polling baseline so Cephalon.MultiTenancy.Governance owns opt-in generic-host scheduling, startup polling, and last-run runtime-state reporting around the bounded proof polling runner while still leaving DNS publication, HTTP publication, tenant-admin, public onboarding, and provider-backed mutation outside that slice boundary; HTTP file proof publication later shipped in ENG-253
  • Sprint 65: shipped ENG-253 multi-tenancy governance HTTP proof publication baseline so Cephalon.MultiTenancy.Governance owns host-agnostic HTTP proof publication state and Cephalon.MultiTenancy.Governance.AspNetCore can serve published proof files from ASP.NET Core hosts while still leaving DNS/provider mutation, tenant-admin, and public onboarding outside the current proof
  • Sprint 66: shipped ENG-254 multi-tenancy governance tenant administration workflow baseline so Cephalon.MultiTenancy.Governance owns host-driven grant/suspend/expire membership plus issue/accept/revoke/expire invitation commands over the same stores while still leaving host-adapter endpoint mapping, tenant-admin UI, public onboarding, provider-specific invitation senders, and identity-provider sync outside that slice boundary; the ASP.NET Core command endpoint later shipped in ENG-255
  • Sprint 67: shipped ENG-255 multi-tenancy governance ASP.NET Core tenant administration endpoint baseline so Cephalon.MultiTenancy.Governance.AspNetCore maps the optional fail-closed POST /engine/tenant-administration/commands endpoint over ITenantAdministrationWorkflow and reports tenant-administration-http-endpoints runtime truth while still leaving tenant-admin UI, public onboarding, provider-specific invitation senders, and identity-provider sync outside the current proof
  • Sprint 68: shipped ENG-256 multi-tenancy governance invitation delivery dispatch baseline so Cephalon.MultiTenancy.Governance owns host-agnostic ITenantInvitationDeliveryDispatcher, ITenantInvitationDeliverySender, delivery run catalog, outcome metadata, tenancy.invitation.delivery-dispatch, diagnostics 4548-4549, and delivery readiness/run-state truth while still leaving email/SMS/chat/identity-provider sender implementations, public onboarding, tenant-admin UI, and identity-provider sync outside the current proof
  • Sprint 69: shipped ENG-257 multi-tenancy governance HTTP invitation delivery sender baseline so Cephalon.MultiTenancy.Governance.HttpDelivery owns the optional http-webhook ITenantInvitationDeliverySender, configuration/code-first registration, bounded JSON webhook dispatch, provider-message id capture, diagnostics 4550-4551, and focused runtime/tooling/reference-doc coverage while still leaving provider-specific email/SMS/chat/CRM/identity-provider connectors, durable retry queues, callbacks, public onboarding, tenant-admin UI, and identity-provider sync outside the current proof
  • Sprint 70: shipped ENG-258 multi-tenancy governance HTTP invitation delivery webhook signing baseline so Cephalon.MultiTenancy.Governance.HttpDelivery can HMAC-sign the exact JSON body plus dispatch timestamp, emit signature/timestamp/key-id headers, and record safe signed-delivery metadata while still leaving provider-specific invitation connectors, durable retry queues, callback reconciliation, public onboarding, tenant-admin UI, and identity-provider sync outside the current proof
  • Sprint 71: shipped ENG-259 multi-tenancy governance HTTP invitation delivery retry baseline so Cephalon.MultiTenancy.Governance.HttpDelivery can retry configured transient status codes and transport failures with bounded in-process attempts/backoff, fresh requests per attempt, and safe attempt/retry metadata while still leaving durable retry queues, provider-specific delivery-status callback endpoints or provider polling, provider-specific invitation connectors, public onboarding, tenant-admin UI, and identity-provider sync outside the current proof
  • Sprint 72: shipped ENG-260 multi-tenancy governance HTTP invitation delivery idempotency baseline so Cephalon.MultiTenancy.Governance.HttpDelivery emits provider-neutral idempotency headers derived from tenant/invitation/channel/sender or caller-supplied dispatch metadata, keeps the key stable across retry attempts, and records safe idempotency metadata while still leaving durable retry queues, provider-specific delivery-status callback endpoints or provider polling, provider-specific invitation connectors, public onboarding, tenant-admin UI, and identity-provider sync outside the current proof
  • Sprint 73: shipped ENG-261 multi-tenancy governance invitation delivery status reconciliation baseline so Cephalon.MultiTenancy.Governance now owns host-agnostic ITenantInvitationDeliveryStatusReconciler, delivery status/status-outcome metadata, tenancy.invitation.delivery-status-reconciliation, diagnostics 4552-4553, and tenant-invitations/tenant-administration runtime metadata for latest provider or receiver status observations while still leaving provider-specific callback endpoints, provider polling, provider-specific invitation connectors, durable retry queues, public onboarding, tenant-admin UI, and identity-provider sync outside the current proof
  • Sprint 74: shipped ENG-262 behavior REST profile runtime ownership metadata baseline so Cephalon.Behaviors.Http now keeps profile metadata explicitly non-publishing while /engine/rest-endpoints, /engine/rest-endpoint-candidates, and snapshot.RestEndpoints expose stable runtime metadata keys for application-owned publication activation, Cephalon-owned materialization/runtime catalog truth, profile metadata ownership, and explicit activation mode for MapProfile<TBehavior>() and generated-profile shorthands — issue #771
  • Sprint 75: shipped ENG-263 eventing subscription execution binding catalog baseline so Cephalon.Eventing now exposes IEventSubscriptionExecutionBindingCatalog plus stable EventSubscriptionRuntimeMetadataKeys, while Wolverine remains an optional provider-managed binding proof instead of an engine requirement — issue #772
  • Sprint 76: shipped ENG-264 eventing subscription execution readiness catalog baseline so Cephalon.Eventing now exposes IEventSubscriptionExecutionReadinessCatalog and projects executionReadiness, executionPath, and executionReadinessReasons through event-subscriptions for declared-only, application-managed, hosted-execution-linked, and Wolverine runtime-bound paths — issue #773
  • Sprint 77: shipped ENG-265 eventing subscription readiness operator-surface baseline so readiness contracts now live in Cephalon.Abstractions.Data, Cephalon.Eventing owns the implementation, ASP.NET Core exposes /engine/event-subscription-readiness, and snapshot.EventSubscriptionExecutionReadiness carries the same host-agnostic readiness answer - issue #774
  • Sprint 78: shipped ENG-266 agentics tool-run operator-surface baseline so run-state contracts now live in Cephalon.Abstractions.Agentics, Cephalon.Agentics owns dispatcher/reporting implementation, ASP.NET Core exposes /engine/agent-tool-runs, and snapshot.AgentToolRuns carries the same host-agnostic run-state answer - issue #775
  • Sprint 79: shipped ENG-267 retrieval knowledge-index operator-surface baseline so index-state contracts now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval owns indexing/query implementation, ASP.NET Core exposes /engine/knowledge-indexes, and snapshot.KnowledgeIndexes carries the same host-agnostic index-state answer - issue #776
  • Sprint 80: shipped ENG-268 retrieval reindex operator-action baseline so indexing command contracts now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval owns the bounded reindex implementation, and ASP.NET Core exposes POST /engine/knowledge-indexes/{collectionId}/reindex without taking a dependency on retrieval implementation types - issue #777
  • Sprint 81: shipped ENG-269 agentics tool execution operator-action baseline so dispatcher command contracts now live in Cephalon.Abstractions.Agentics, Cephalon.Agentics owns the bounded tool-dispatch implementation, and ASP.NET Core exposes POST /engine/agent-tools/{toolId}/runs without taking a dependency on agentics implementation types - issue #778
  • Sprint 82: shipped ENG-270 retrieval background reindex scheduler baseline so Cephalon.Retrieval can register an opt-in generic-host scheduler over the existing IKnowledgeIndexer, emit retrieval.background-reindexing, and surface backgroundReindexing* runtime metadata without claiming distributed scheduling, vector search, or provider-specific search ownership - issue #779
  • Sprint 83: shipped ENG-271 eventing in-process subscription execution baseline so lightweight hosts can opt into a Cephalon-managed direct publisher over registered IEventSubscriptionExecutor services without requiring Wolverine or claiming durable broker/inbox/retry ownership - issue #780
  • Sprint 84: shipped ENG-272 eventing publication operator-action baseline so publication command contracts now live in Cephalon.Abstractions.Data, Cephalon.Eventing owns the bounded dispatcher over the active IEventPublisher, and ASP.NET Core exposes POST /engine/event-publications without taking a dependency on eventing implementation types - issue #781
  • Sprint 85: shipped ENG-273 eventing in-process subscription retry baseline so the direct process-local publisher can retry transient executor failures with bounded attempts, retry-scheduled runtime observations, and explicit non-durable retry metadata without claiming broker-owned retry queues or distributed scheduling - issue #782
  • Sprint 86: shipped ENG-274 eventing in-process subscription idempotency baseline so the direct process-local publisher can suppress duplicate completed subscriptionId + publicationId executions inside a bounded retention window, report skipped runtime observations, and project explicit non-durable idempotency metadata without claiming durable inbox ownership or cross-node exactly-once delivery - issue #783
  • Sprint 87: shipped ENG-275 eventing publication runtime operator-state baseline so publication runtime-state contracts now live in Cephalon.Abstractions.Data, Cephalon.Eventing reports direct in-process succeeded/failed/skipped outcomes and outbox-backed accepted handoff posture, ASP.NET Core exposes /engine/event-publications/runtime*, and snapshot.EventPublicationStates carries the same bounded publication answer without claiming downstream broker delivery - issue #784
  • Sprint 88: shipped ENG-276 Wolverine bounded subscription retry terminal failure so the optional provider-managed subscription lane now projects bounded-fixed-delay retry metadata, honors SubscriptionMaxAttempts, reports exhausted attempts as terminal failed runtime state, and stops requeueing poison subscription messages forever without making Wolverine an engine requirement - issue #785
  • Sprint 89: shipped ENG-277 Wolverine dispatch terminal retry failure so the optional provider-managed dispatch loop now projects bounded-fixed-delay dispatch retry metadata, honors DispatchMaxAttempts, reports exhausted no-destination or publish failures as terminal failed runtime state, and stops poison staged publications from re-entering pending dispatch reads without claiming broker-specific dead-letter ownership - issue #786
  • Sprint 90: shipped ENG-278 Wolverine dispatch publish-exception terminal proof so the optional provider-managed dispatch loop now has focused coverage for real PublishAsync(...) exceptions: retryable publish failures keep routing = publish, exceptionType, and nextRetryAtUtc, while exhausted publish failures become terminal failed observations and leave pending-dispatch reads without claiming broker-specific dead-letter ownership - issue #787
  • Sprint 91: shipped ENG-279 first-class event-dispatch terminal-failure runtime posture so /engine/event-dispatches, /engine/event-dispatches/terminal-failures, /engine/event-dispatch-runtimes, technology surfaces, and snapshot.EventDispatch* expose terminal dispatch failures through typed state/summary fields instead of forcing operators to parse reported.* metadata - issue #788
  • Sprint 92: shipped ENG-280 Agentics bounded in-process retry posture so ExecutionMaxAttempts can retry failed managed tool executor attempts inside the dispatcher lane, retry-scheduled run-state observations and /engine/agent-tool-runs/retry-pending expose pending process-local retries, and the agentics technology surface reports retry policy without claiming durable queues or provider AI orchestration - issue #789
  • Sprint 93: shipped ENG-281 Agentics process-local duplicate-run idempotency posture so EnableExecutionIdempotency can suppress duplicate completed toolId + runId executions inside the dispatcher lane, DuplicateCompleted plus /engine/agent-tool-runs/idempotency-duplicates expose the operator posture, and the agentics technology surface reports non-durable process-local idempotency without claiming durable inboxes, cross-node exactly-once delivery, or provider AI orchestration - issue #790
  • Sprint 94: shipped ENG-282 Agentics approval-required and terminal-failure operator posture so /engine/agent-tool-runs/approval-required, /engine/agent-tool-runs/terminal-failures, AgentToolRunState.TerminalFailure, and the agentics technology surface expose approval-blocked and terminal failed tool runs without claiming durable approval workflows, dead-letter systems, durable queues, or provider AI orchestration - issue #791
  • Sprint 95: shipped ENG-283 Retrieval query operator action seam so query command contracts now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval owns the bounded lexical query implementation, and ASP.NET Core exposes POST /engine/knowledge-indexes/{collectionId}/queries without taking a dependency on retrieval implementation types - issue #792
  • Sprint 95: shipped ENG-284 Multi-tenancy invitation delivery status callback endpoint baseline so Cephalon.MultiTenancy.Governance.AspNetCore exposes fail-closed normalized POST /engine/tenant-invitations/delivery-status ingress over ITenantInvitationDeliveryStatusReconciler with provider-message-match enforcement and runtime-surface truth - issue #793
  • Sprint 95: shipped ENG-285 Multi-tenancy invitation delivery status callback signature verification baseline so that normalized callback endpoint can require provider-neutral Cephalon HMAC signatures over the exact JSON body, fail closed before reconciliation, and report signature verification posture without exposing secrets or signature values - issue #800
  • Sprint 95: shipped ENG-286 Multi-tenancy invitation delivery status callback replay protection baseline so the signed normalized callback endpoint can reject duplicate signed requests inside a bounded process-local replay window, report replay policy/key/scope/durability/retention/cache posture, and stay explicit that provider-specific or distributed callback inboxes and cross-node replay protection remain future work - issue #801
  • Sprint 95: shipped ENG-287 Multi-tenancy invitation delivery status observation store baseline so the host-agnostic reconciler records normalized accepted and denied delivery-status observations into an in-memory or opt-in local JSON store, reports observation-store kind/durability/scope/history/count/latest posture through tenant-invitations, and stays explicit that provider-specific callback inboxes, provider polling, and distributed replay remain future work - issue #802
  • Sprint 95: shipped ENG-288 Multi-tenancy invitation delivery status observation endpoint baseline so ASP.NET Core hosts can map bounded/filterable GET /engine/tenant-invitations/delivery-status/observations reads over ITenantInvitationDeliveryStatusObservationStore, report observation route/auth/limit posture through tenant-invitation-delivery-status-http-endpoints, and stay explicit that provider-specific callback inboxes, provider polling, distributed replay ledgers, and exactly-once delivery remain future work - issue #803
  • Sprint 95: shipped ENG-289 Multi-tenancy invitation delivery dispatch endpoint baseline so ASP.NET Core hosts can map fail-closed POST /engine/tenant-invitations/delivery-dispatches actions over ITenantInvitationDeliveryDispatcher, report route/auth/status-mapping/boundary posture through tenant-invitation-delivery-http-endpoints, and stay explicit that provider-specific senders, distributed retry queues, public onboarding, tenant-admin UI, identity-provider sync, and provider polling remain future work - issue #804
  • Sprint 95: shipped ENG-290 Multi-tenancy invitation delivery durable retry queue baseline so the governance core can queue retryable sender failures through opt-in ITenantInvitationDeliveryRetryStore, persist them to a local JSON file when configured, replay them through bounded manual ITenantInvitationDeliveryRetryRunner.RetryPendingAsync(...), and report queue counts/latest retry posture through tenant-invitations without claiming automatic background scheduling, distributed queues, cross-node leases, provider-specific senders, or exactly-once delivery - issue #805
  • Sprint 96: shipped ENG-291 Multi-tenancy invitation delivery background retry scheduling baseline so the governance core can opt into TenantInvitationDeliveryRetryHostedService, schedule the same bounded retry runner on startup/interval, report ITenantInvitationDeliveryRetryRuntimeCatalog state and deliveryRetryBackground* metadata through tenant-invitations, and stay explicit that distributed queues, cross-node leases, provider-specific senders, provider polling/callback inboxes, public onboarding, tenant-admin UI, identity-provider sync, and exactly-once delivery remain future work - issue #806
  • Sprint 97: shipped ENG-292 Multi-tenancy invitation delivery retry execution coordination baseline so manual and background retry passes share a process-local skip-overlap guard, overlapping passes return already-running without dispatching or mutating the retry queue, and ITenantInvitationDeliveryRetryExecutionCoordinationCatalog plus deliveryRetryExecutionCoordination* metadata expose the runtime truth without claiming distributed queues, cross-node leases, or exactly-once delivery - issue #807
  • Sprint 98: shipped ENG-293 Multi-tenancy invitation delivery SMTP sender baseline so Cephalon.MultiTenancy.Governance.SmtpDelivery owns the optional smtp-email ITenantInvitationDeliverySender, configuration/code-first registration, templated email preparation, deterministic SMTP message ids, safe context headers/metadata, replaceable ISmtpInvitationDeliveryClient, diagnostics 4558-4559, and focused runtime/tooling/reference-doc coverage while still leaving provider-specific email APIs such as SendGrid, Mailgun, SES, or Microsoft Graph, SMS/chat/CRM/identity-provider connectors, bounce/callback translation, provider polling, distributed queues, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #808
  • Sprint 99: shipped ENG-294 Multi-tenancy invitation delivery SendGrid sender baseline so Cephalon.MultiTenancy.Governance.SendGridDelivery owns the optional sendgrid-email ITenantInvitationDeliverySender, configuration/code-first registration, templated SendGrid Mail Send API payloads, safe context headers/custom arguments/categories, sandbox-mode validation, provider X-Message-ID capture, replaceable ISendGridInvitationDeliveryClient, diagnostics 4560-4561, and focused runtime/tooling/reference-doc coverage while still leaving SendGrid Event Webhook callback translation, webhook signature verification, bounce handling, provider polling, dynamic-template lifecycle management, non-SendGrid email API connectors, SMS/chat/CRM/identity-provider connectors, distributed queues, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #809
  • Sprint 100: shipped ENG-295 Multi-tenancy invitation delivery SendGrid Event Webhook callback translation baseline so Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore owns the optional fail-closed POST /engine/tenant-invitations/delivery-status/sendgrid translator, bounded SendGrid event-array parsing, Cephalon custom-argument extraction, sg_message_id to X-Message-ID correlation, status vocabulary mapping, safe callback metadata, diagnostics 4562, tenant-invitation-delivery-sendgrid-status-callbacks, and focused hosting/tooling/reference-doc coverage while still leaving SendGrid signed-webhook verification, durable callback inboxes, distributed replay protection, provider polling, dynamic-template lifecycle management, non-SendGrid callback translation, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #810
  • Sprint 101: shipped ENG-296 Multi-tenancy invitation delivery SendGrid signed Event Webhook verification so Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore can require SendGrid ECDSA-SHA256 signatures over timestamp plus exact raw request body bytes before JSON parsing or reconciliation, report safe signature posture through callback results, metadata, diagnostics 4563, and the same runtime surface, and stay explicit that durable inboxes, distributed replay, provider polling, and non-SendGrid callback semantics remain outside this proof - issue #811
  • Sprint 102: shipped ENG-297 Multi-tenancy invitation delivery SendGrid signed Event Webhook replay protection baseline so Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore can reject duplicate verified signed callbacks inside a bounded process-local replay window, report safe replay posture through callback results, metadata, diagnostics 4564, and the same runtime surface, and stay explicit that durable inboxes, distributed replay ledgers, provider polling, and exactly-once delivery remain outside this proof - issue #812
  • Sprint 103: shipped ENG-298 Multi-tenancy invitation delivery SendGrid event-id idempotency baseline so Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore can skip duplicate translated sg_event_id observations before reconciliation, report safe event-id idempotency posture through callback results, metadata, diagnostics 4565, and the same runtime surface, and stay explicit that durable callback inboxes, distributed event-id ledgers, provider polling, and exactly-once delivery remain outside this proof - issue #813
  • Sprint 104: shipped ENG-299 Multi-tenancy invitation delivery Mailgun sender baseline so Cephalon.MultiTenancy.Governance.MailgunDelivery owns the optional mailgun-email ITenantInvitationDeliverySender, configuration/code-first registration, templated multipart Messages API payloads, safe v:* variables and h:* headers, Mailgun test mode, provider JSON id capture, replaceable IMailgunInvitationDeliveryClient, diagnostics 4566-4567, and focused runtime/tooling/reference-doc coverage while at that point still leaving Mailgun callback translation/signature verification, provider polling, durable callback inboxes, distributed queues, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #814
  • Sprint 105: shipped ENG-300 Multi-tenancy invitation delivery Mailgun webhook callback translation baseline so Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore owns the optional fail-closed POST /engine/tenant-invitations/delivery-status/mailgun endpoint, bounded Mailgun JSON object/array parsing, user-variable context extraction, message.headers.message-id correlation, Mailgun status translation, safe callback metadata, diagnostics 4568, and the tenant-invitation-delivery-mailgun-status-callbacks runtime surface while at that point still leaving Mailgun signature verification (later ENG-301), replay-token rejection (later ENG-302), event-id idempotency (later ENG-303), durable callback inboxes, distributed replay/event-id ledgers, provider polling, exactly-once delivery, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #815
  • Sprint 106: shipped ENG-301 Multi-tenancy invitation delivery Mailgun signed webhook verification baseline so Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore can require Mailgun HMAC-SHA256 verification over timestamp + token, accepts parent-signature for subaccount events when configured, rejects invalid signed callbacks before reconciliation, reports safe signature metadata plus diagnostic 4569, and keeps replay-token rejection (later ENG-302), event-id idempotency (later ENG-303), durable callback inboxes, distributed replay/event-id ledgers, provider polling, and exactly-once delivery outside this proof - issue #816
  • Sprint 107: shipped ENG-302 Multi-tenancy invitation delivery Mailgun signed webhook replay protection baseline so Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore can reject duplicate verified Mailgun webhook tokens with 409 inside a bounded process-local retention window, stores only token fingerprints, reports safe replay metadata plus diagnostic 4570, and keeps durable callback inboxes, distributed replay/event-id ledgers, provider polling, and exactly-once delivery outside this proof - issue #817
  • Sprint 108: shipped ENG-303 Multi-tenancy invitation delivery Mailgun event-id idempotency baseline so Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore can skip duplicate translated event-data.id observations before reconciliation, report safe event-id idempotency posture through callback results, metadata, diagnostics 4571, and the same runtime surface, and stay explicit that durable callback inboxes, distributed event-id ledgers, provider polling, and exactly-once delivery remain outside this proof - issue #818
  • Sprint 109: shipped ENG-304 Multi-tenancy invitation delivery Microsoft Graph sender baseline so Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery owns the optional microsoft-graph-email ITenantInvitationDeliverySender, configuration/code-first registration, templated Graph sendMail payloads, safe x-* internet message headers, Graph request-id metadata, replaceable IMicrosoftGraphInvitationDeliveryClient and IMicrosoftGraphInvitationDeliveryAccessTokenProvider seams, diagnostics 4572-4573, and focused runtime/tooling/reference-doc coverage while still leaving Microsoft Entra app registration, permission consent, mailbox access policy, token-provider implementation before ENG-305, delivery completion after Graph accepts sendMail, Graph change notifications, provider polling, callback inboxes, Amazon SES v2 handoff later shipped through ENG-306, additional provider-specific email APIs beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider connectors, distributed queues, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #819
  • Sprint 110: shipped ENG-305 Multi-tenancy invitation delivery Microsoft Graph Azure Identity token provider baseline so Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery.AzureIdentity owns optional DefaultAzureCredential/explicit TokenCredential access-token acquisition for the Microsoft Graph sender, configuration/code-first scopes, tenant id, managed-identity client id, authority-host selection, safe credential toggles, diagnostics 4574-4575, and focused runtime/tooling/reference-doc coverage while still leaving Microsoft Entra app registration, Graph Mail.Send permission consent, mailbox access policy, credential lifecycle policy beyond the selected Azure credential, delivery completion after Graph accepts sendMail, Graph change notifications, provider polling, callback inboxes, Amazon SES v2 handoff later shipped through ENG-306, additional provider-specific email APIs beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider connectors, distributed queues, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #820
  • Sprint 111: shipped ENG-306 Multi-tenancy invitation delivery Amazon SES sender baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery owns the optional amazon-ses-email ITenantInvitationDeliverySender, configuration/code-first registration, templated SES v2 SendEmail payloads, safe region/configuration-set/status/message-id/tag/recipient metadata, replaceable IAmazonSesInvitationDeliveryClient seam, diagnostics 4576-4577, and focused runtime/tooling/reference-doc coverage while still leaving AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox exit, configuration-set event destination setup, provider polling, callback inboxes, SMS/chat/CRM/identity-provider connectors, distributed queues, public onboarding, tenant-admin UI, and identity-provider sync outside this proof; Amazon SES over SNS callback translation later shipped through ENG-307 - issue #821
  • Sprint 112: shipped ENG-307 Multi-tenancy invitation delivery Amazon SES SNS callback translation baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore owns the optional fail-closed POST /engine/tenant-invitations/delivery-status/amazon-ses translator, bounded SNS Notification parsing, SES event JSON unwrapping, Cephalon mail.tags context extraction, mail.messageId correlation, SES delivery status mapping, safe callback metadata, diagnostics 4578, and tenant-invitation-delivery-amazon-ses-status-callbacks while SNS signature verification, process-local SNS replay protection, SNS message-id idempotency, and verified SNS subscription confirmation later shipped through ENG-308, ENG-309, ENG-310, and ENG-311; durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI, and identity-provider sync remain outside this proof - issue #822
  • Sprint 113: shipped ENG-308 Multi-tenancy invitation delivery Amazon SES SNS signature verification baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore can require SNS envelope verification before translation, enforce signature version 2 and allowed TopicArn by default, validate HTTPS Amazon SNS signing-certificate URLs, optionally use pinned PEM certificates for controlled tests, record safe signature metadata, emit diagnostics 4579, and report signature-version/topic/certificate posture through tenant-invitation-delivery-amazon-ses-status-callbacks while process-local SNS replay protection, SNS message-id idempotency, and verified SNS subscription confirmation later shipped through ENG-309, ENG-310, and ENG-311; durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI, and identity-provider sync remain outside this proof - issue #823
  • Sprint 114: shipped ENG-309 Multi-tenancy invitation delivery Amazon SES SNS replay protection baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore can reject duplicate verified SNS callbacks by bounded process-local TopicArn plus MessageId fingerprints before reconciliation, record safe replay metadata, emit diagnostics 4580, and report replay policy/key/scope/durability/retention/cache posture through tenant-invitation-delivery-amazon-ses-status-callbacks while still leaving observation-store-backed SNS message-id idempotency to ENG-310 and verified SNS subscription confirmation to ENG-311; SES event-destination setup, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #824
  • Sprint 115: shipped ENG-310 Multi-tenancy invitation delivery Amazon SES SNS message-id idempotency baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore can skip duplicate translated SNS MessageId observations before reconciliation through ITenantInvitationDeliveryStatusObservationStore, return aggregate duplicateEvents plus per-event duplicate-skipped outcomes, record safe idempotency metadata, emit diagnostics 4581, and report message-id idempotency policy/key/scope/store-durability posture through tenant-invitation-delivery-amazon-ses-status-callbacks while still leaving verified SNS subscription confirmation to ENG-311; SES event-destination setup, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #825
  • Sprint 116: shipped ENG-311 Multi-tenancy invitation delivery Amazon SES SNS subscription confirmation baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore can confirm verified SNS SubscriptionConfirmation envelopes from allowed topics through replaceable IAmazonSesSnsSubscriptionConfirmationClient, return subscription-confirmation aggregate fields, emit diagnostics 4582-4583, and report confirmation ownership/policy/timeout posture through tenant-invitation-delivery-amazon-ses-status-callbacks while still leaving SNS topic/subscription creation, SES event-destination setup, subscription lifecycle governance, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #826
  • Sprint 117: shipped ENG-312 Multi-tenancy invitation delivery Amazon SES SNS unsubscribe confirmation observation baseline so Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore can observe verified SNS UnsubscribeConfirmation envelopes from allowed topics, validate but never invoke SubscribeURL, return unsubscribe-confirmation aggregate fields, emit diagnostic 4584, and report unsubscribe-confirmation ownership/action/SubscribeURL posture through tenant-invitation-delivery-amazon-ses-status-callbacks while still leaving SNS topic/subscription creation, SES event-destination setup, automatic resubscribe/restore, subscription lifecycle governance, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI, and identity-provider sync outside this proof - issue #827
  • Sprint 118: shipped ENG-313 Multi-tenancy delivery status observation rollup operator summary so Cephalon.MultiTenancy.Governance.AspNetCore returns filtered status/outcome/source/channel/sender/tenant summaries with bounded GET /engine/tenant-invitations/delivery-status/observations responses, reports observation-summary ownership/scope/dimensions through tenant-invitation-delivery-status-http-endpoints, and stays explicit that provider-specific callback inboxes, provider polling, distributed replay ledgers, and exactly-once delivery remain future work - issue #828
  • Sprint 119: shipped ENG-314 Multi-tenancy delivery status observation attention drill-down baseline so Cephalon.MultiTenancy.Governance.AspNetCore classifies matched observations into stable attention categories, supports attention= drill-down filtering for delivery-failed, delivery-deferred, delivery-suppressed, delivery-unknown, reconciliation-gap, and recording-gap, reports attention ownership/scope/categories through tenant-invitation-delivery-status-http-endpoints, and stays explicit that this remains an operator/audit projection over normalized observations, not provider-specific callback inbox, provider polling, distributed replay, or exactly-once delivery ownership - issue #829
  • Sprint 120: shipped ENG-315 Multi-tenancy delivery status observation remediation hints baseline so Cephalon.MultiTenancy.Governance.AspNetCore derives deterministic remediation hints from matched normalized observations before response limiting, exposes stable action labels plus hint descriptors with counts/latest timestamps/drill-down filters, reports remediation-hint ownership/scope/actions through tenant-invitation-delivery-status-http-endpoints, and stays explicit that these are operator guidance only, not provider polling, distributed remediation execution, callback inbox, distributed replay, or exactly-once delivery ownership - issue #830
  • Sprint 121: shipped ENG-316 Multi-tenancy delivery status observation remediation action filter baseline so Cephalon.MultiTenancy.Governance.AspNetCore can summarize matched observations by stable remediation action, supports remediation= drill-down filtering over the same normalized observation set, reports remediation-filter ownership/scope through tenant-invitation-delivery-status-http-endpoints, and stays explicit that this is an operator/audit projection only, not provider polling, distributed remediation execution, callback inbox, distributed replay, or exactly-once delivery ownership - issue #831
  • Sprint 122: shipped ENG-317 Multi-tenancy delivery status observation provider-message drill-down baseline so Cephalon.MultiTenancy.Governance.AspNetCore can summarize matched observations by providerMessageId, supports providerMessageId= drill-down filtering over the same normalized observation set, reports provider-message filter ownership/scope through tenant-invitation-delivery-status-http-endpoints, and stays explicit that this is an operator/audit projection only, not provider polling, provider-specific callback inbox, distributed replay, or exactly-once delivery ownership - issue #832
  • Later / not scheduled yet: actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, distributed retry queues, provider-specific or distributed callback inboxes, cross-node callback replay protection, distributed event-id ledgers, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, identity-provider synchronization, public onboarding, and tenant-admin UI/backoffice flows for Cephalon.MultiTenancy.Governance, further cloud/platform integrations beyond the shipped phase 6 baseline, ENG-054 hybrid-runtime service-mesh and serverless expansion, and future solution-level expansion only when an explicit adoption scenario needs them
  • prefer stabilizing the shipped surface over inventing new layers too early
  • keep the engine configuration-driven and host-agnostic by default
  • keep logical data selection separate from physical database topology so one codebase can move between layouts without rewriting hosts
  • keep future-facing technology choices additive through explicit technology profiles instead of blueprint explosion
  • treat scaffolding, CLI, and benchmark coverage as part of the engine product, not side tools
  • make every new runtime feature observable, testable, and benchmarkable
  • prove one relational-first golden path before widening provider-family or hybrid-runtime claims
  • keep orchestration additive and delay distributed runners until package loading, lifecycle, and policy are strong enough
  • make every mixed-maturity family declare whether a surface is taxonomy-only, application-managed, cephalon-managed, or provider-managed before broadening the claim
  • treat the eventing-family proof as landed through ENG-231 plus the ENG-263/ENG-264/ENG-265 read seams, the ENG-271 core in-process execution lane, the ENG-272 bounded publication operator action, the ENG-273 bounded process-local retry proof, the ENG-274 bounded process-local idempotency proof, the ENG-275 publication runtime-state read proof, the ENG-276 optional Wolverine bounded provider-managed subscription retry proof, the ENG-277/ENG-278 optional Wolverine bounded provider-managed dispatch terminal proofs, and the ENG-279 first-class terminal dispatch-state operator posture, the agentics-family proof as landed through ENG-232 plus the ENG-266/ENG-269 operator seams, ENG-280 bounded process-local retry posture, ENG-281 bounded process-local duplicate-completed idempotency posture, and ENG-282 approval-required plus terminal-failure operator posture, and the retrieval-family proof as landed through ENG-233 plus the ENG-267/ENG-268/ENG-270/ENG-283 operator and scheduler seams, then keep the same narrow managed-proof bias over broad descriptor growth in remaining mixed-maturity families
  • treat intentional metadata-only or catalog-only work as valid only when docs, planning, and runtime surfaces label it honestly

Status: substantially complete

What is already in place:

  • app model and blueprint contracts
  • technology-profile contract for future-facing workload guidance
  • module discovery and dependency ordering
  • lifecycle baseline with runtime status
  • manifest v2 and runtime introspection endpoints
  • ASP.NET Core and worker host adapters
  • transport adapter split
  • scaffold generation and CLI baseline
  • observability baseline
  • benchmark baseline

What still belongs to foundation hardening:

  • richer runtime failure and restart policies beyond the shipped baseline
  • more actionable diagnostics for module/package authors

Phase 1: SDK hardening and external adoption

Section titled “Phase 1: SDK hardening and external adoption”

Status: substantially complete

Goal: turn the current repo from “good internal foundation” into something other teams can adopt predictably.

Deliverables:

  • package/version compatibility guidance
  • CLI polish for real developer workflows
  • generated output that stays aligned across Cephalon.Scaffolding, Cephalon.Cli, Cephalon.TemplatePack, and the repository package catalog
  • GraphQL transport delivery that keeps the runtime catalog, scaffold output, tests, and component docs aligned with the adapter split
  • DocFX-ready XML comments across the supported published assembly set, with tests kept outside that publishing boundary unless promoted intentionally
  • technology profiles that stay aligned across runtime introspection, scaffolding, CLI, and template defaults
  • companion packages that turn selected technology profiles into reusable runtime primitives without bloating the engine core
  • module-authoring starters and reference packages that stay aligned with runtime contracts
  • operational polish on top of the shipped failure-policy and health/telemetry baselines

Exit criteria:

  • a new team can create a Cephalon app without copying code out of this repo manually
  • a new module can be authored from a supported starter path
  • generated apps, docs, package references, and install surfaces stay aligned with the shipped engine conventions

Current note:

  • the supported phase-1 adoption baseline is now shipped across public-surface hardening, GraphQL transport delivery, compatibility guidance, DocFX-ready XML comments, the explicit test-harness visibility policy that keeps shared helpers internal while leaving only framework-required xUnit classes and a narrow reflective transport-contract exception public in tests/Cephalon.Tests, the release package-artifact baseline that defines the intended shipped NuGet/template surface explicitly, the shipped checksum/provenance manifest follow-through under ENG-032, and a dedicated .NET tool install surface for Cephalon.Cli

Status: substantially complete

Goal: make Cephalon safe to operate in real environments.

Deliverables:

  • deeper readiness and liveness semantics beyond the shipped baseline
  • richer runtime failure, stop, and restart policies beyond the shipped baseline
  • richer structured diagnostics and event IDs across packages
  • ILogger provider integration such as Serilog when hosts need richer sinks, enrichers, or log-routing behavior without inventing a new logging abstraction
  • ASP.NET Core request/response logging with bounded body capture and trace/log correlation over the shared ILogger pipeline
  • clearer operational answers to “what loaded, what started, what failed, and why?”
  • benchmark-driven performance guardrails for hot engine paths

Current inventory:

  • docs/operational-hardening-gap-inventory.md now records the shipped baseline versus the remaining phase-2 gaps so follow-through work stays grounded in the code that already exists
  • that inventory now includes shipped Cephalon.Observability.OpenTelemetry and Cephalon.Observability.Serilog companion packages plus shipped Cephalon.Observability.CassandraDependencies, Cephalon.Observability.ClickHouseDependencies, Cephalon.Observability.ConsulDependencies, Cephalon.Observability.ElasticsearchDependencies, Cephalon.Observability.HttpDependencies, Cephalon.Observability.KafkaDependencies, Cephalon.Observability.MemcachedDependencies, Cephalon.Observability.MongoDbDependencies, Cephalon.Observability.MqttDependencies, Cephalon.Observability.MySqlDependencies, Cephalon.Observability.NatsDependencies, Cephalon.Observability.Neo4jDependencies, Cephalon.Observability.OpenSearchDependencies, Cephalon.Observability.OracleDependencies, Cephalon.Observability.PostgresDependencies, Cephalon.Observability.RabbitMqDependencies, Cephalon.Observability.RedisDependencies, and Cephalon.Observability.SqlServerDependencies companion packages, together with a published runtime diagnostics catalog, runtime-story surface, configurable failure-policy warmup/drain/backoff semantics, opt-in ASP.NET Core request/response body logging with request/trace correlation plus default sensitive-value redaction, explicit release-validation guidance for health/export conventions, and refreshed benchmark guardrails that separate prepared composition/lifecycle hot paths plus strict trust-policy composition plus bounded, correlated, and concurrent ASP.NET Core request-logging paths from benchmark harness setup
  • the remaining cloud-vendor tracing/export follow-through has been re-scoped into phase 6 cloud and platform integrations because the expanded self-hosted plus AWS plus Azure plus GCP plus Huawei Cloud plus Alibaba Cloud plus Oracle Cloud plus DigitalOcean plus Red Hat OpenShift plus VMware Tanzu plus Kubernetes target list, together with the downstream Cloudflare/custom-provider guidance path and the now-explicit Grafana Cloud OTLP/header follow-through target, is broader than the shipped phase-2 operational baseline

Exit criteria:

  • operators can diagnose engine startup and module failures quickly
  • host health semantics are predictable across ASP.NET Core and worker hosts
  • performance regressions in composition/runtime/scaffolding are caught intentionally

Phase 3: Extensibility and package loading

Section titled “Phase 3: Extensibility and package loading”

Status: substantially complete

Goal: let Cephalon load and validate independently shipped module packages.

Current baseline already in place:

  • explicit package assembly paths can be declared through Engine:Discovery:Packages
  • package manifests can be declared through Engine:Discovery:Packages
  • package directories can be scanned through Engine:Discovery:PackageDirectories
  • package metadata can be governed through Engine:PackagePolicy
  • package manifests can declare package-to-package dependencies with version bounds
  • package-loaded modules flow through the same runtime/module contracts
  • package load results are exposed through /engine/packages and manifest v2 metadata
  • package trust and capability policy are exposed through Engine:Trust and /engine/trust-policy
  • package publisher and signer provenance can be declared and evaluated through package manifests and trust allow-lists
  • detached package signatures can be cryptographically verified against trusted public keys or trusted signing certificate chains
  • package manifests can declare external distribution metadata and provenance metadata that stay visible through /engine/packages
  • module-author guidance now covers release-channel, package URI, source revision, build URI, and provenance statement hints for externally distributed packages

Exit criteria:

  • Cephalon can load distributable module packages without relying on one monolithic app assembly
  • package errors fail fast with actionable messages

Phase 4: Execution and orchestration model

Section titled “Phase 4: Execution and orchestration model”

Status: substantially complete

Goal: expand from a composition engine into a richer execution platform.

Current baseline already in place:

  • active modules can now contribute operator-facing execution graphs through IExecutionGraphContributor
  • active modules can now contribute operator-facing hosted executions through IHostedExecutionContributor
  • execution graphs are surfaced through IExecutionRuntimeCatalog, /engine/execution-graphs, and /engine/snapshot
  • hosted executions are surfaced through IHostedExecutionRuntimeCatalog, /engine/hosted-executions, and /engine/snapshot
  • execution-graph lifecycle state is now surfaced through /engine/runtime-story and /engine/snapshot, including load, activate, and deactivate transitions
  • hosted-execution lifecycle state is now surfaced through /engine/runtime-story and /engine/snapshot, including load, activate, and deactivate transitions
  • execution-graph and hosted-execution lifecycle transitions now publish through the shared diagnostics catalog plus cephalon.execution-graphs.transitions and cephalon.hosted-executions.transitions
  • agentic tools can now link back to capability keys, execution graphs, and hosted executions through the existing Cephalon.Agentics contract instead of inventing a parallel orchestration registry
  • /engine/technology-surfaces and /engine/snapshot now project those linked AI/orchestration entries with live runtime-story state
  • graph descriptors stay additive to the existing module/capability model through module ids and capability-key references
  • hosted-execution descriptors stay additive to the existing module and Generic Host model instead of introducing a separate engine-owned runner
  • invalid graph ids, entry nodes, edges, module references, and capability references now fail during build instead of leaking broken runtime metadata
  • invalid hosted-execution ids, source-module references, and cross-module execution-graph references now fail during build instead of leaking broken runtime metadata
  • invalid agent-tool references to unknown capability keys, execution graphs, or hosted executions now fail when the agentic tool catalog is resolved instead of leaking broken orchestration metadata

Exit criteria:

  • orchestration features build on the same runtime model instead of bypassing it
  • long-running engine behavior is observable and policy-driven

Status: substantially complete

Goal: support higher-level solution shapes, not only individual Cephalon apps.

Current baseline already in place:

  • SuiteScaffoldPlan and SuiteScaffoldService now define a separate suite-level scaffold contract for shared projects, shared folders, and per-service slots
  • ScaffoldScopes.Suite now marks suite-owned shared assets explicitly instead of overloading the current single-app scaffold scopes
  • the first suite-shape validation baseline now fails when service-slot dependencies or shared-folder ownership point at undeclared suite identities
  • SuiteBlueprint and BuiltInSuiteBlueprints now define a built-in MicroserviceSuite blueprint that composes repeatable service slots from the existing Microservice app blueprint
  • suite shared-foundation defaults now reuse the shipped Microservice foundation template and package hints instead of defining a second disconnected service-level project shape
  • samples/Cephalon.Sample.MicroserviceSuite now demonstrates a shared foundation project plus separate catalog and orders services on top of the existing Microservice host wiring
  • shared/Cephalon.Sample.MicroserviceSuite.Governance now demonstrates a shared governance package that keeps optional gateway/control-plane guidance additive to the suite sample instead of folding it into the engine or suite contract

Deliverables:

  • MicroserviceSuite blueprint composed from the existing app-level Microservice scaffold contract is now shipped
  • solution-level samples for multiple Cephalon services are now shipped
  • shared governance/convention packages are now shipped in the suite sample baseline
  • optional gateway or control-plane guidance is now documented as an additive sample-level layer rather than a required suite-contract feature

Exit criteria:

  • Cephalon can describe and scaffold not only one service, but an intentional suite of services
  • the suite model still reuses the same engine, blueprint, and package contracts

Status: later

Goal: add deployment-targeted companion integrations without pushing vendor assumptions into the engine core.

Current baseline already in place:

  • cloud-neutral OTLP exporter wiring through Cephalon.Observability.OpenTelemetry
  • the shared Microsoft.Extensions.Logging.ILogger pipeline plus Cephalon.Observability.Serilog
  • correlated ASP.NET Core request/response logging through Engine:Observability:HttpLogging
  • host-agnostic runtime, diagnostics, health, and validation surfaces that later cloud-targeted companions can build on
  • self-hosted collector and runtime defaults plus Azure Monitor, AWS, GCP, Huawei Cloud, Alibaba Cloud, Oracle Cloud, Red Hat OpenShift, DigitalOcean, VMware Tanzu, and Kubernetes are now shipped as the first slices on top of the cloud-neutral OTLP baseline, #120 has now shipped downstream Cloudflare/custom-provider authoring guidance because current Cloudflare docs center Worker-native telemetry export to third-party OTLP destinations rather than a generic external-host sink, #126 has now shipped Grafana Cloud OTLP endpoint wiring plus access-policy-backed auth headers, and #127 has now shipped New Relic native OTLP/api-key guidance as the latest explicit vendor-specific child

Deliverables:

  • self-hosted observability companion follow-through for OTLP-collector-managed deployments and host-managed runtime defaults is now shipped
  • Azure Monitor companion follow-through as the first explicit cloud-specific slice on top of the shared OpenTelemetry baseline is now shipped
  • AWS companion follow-through as the second explicit cloud-specific slice on top of the shared OpenTelemetry baseline is now shipped
  • GCP companion follow-through is now shipped as the third explicit cloud-specific slice on top of the shared OpenTelemetry baseline
  • Huawei Cloud companion follow-through is now shipped as the fourth explicit cloud-specific slice on top of the shared OpenTelemetry baseline
  • Alibaba Cloud companion follow-through is now shipped as the fifth explicit cloud-specific slice on top of the shared OpenTelemetry baseline
  • Oracle Cloud companion follow-through is now shipped as the latest cloud-specific slice on top of the shared OpenTelemetry baseline, centered on Oracle Cloud APM traces/metrics ingestion plus hosted Oracle defaults instead of folding Oracle-specific data-upload and data-key rules back into the generic OTLP package
  • Red Hat OpenShift companion follow-through is now shipped as the latest platform-first slice on top of the shared OpenTelemetry baseline
  • DigitalOcean companion follow-through is now shipped as the latest collector-first slice on top of the shared OpenTelemetry baseline, centered on runtime defaults and collector handoff instead of an over-claimed managed OTLP exporter path
  • VMware Tanzu companion follow-through is now shipped as the latest proxy-first slice on top of the shared OpenTelemetry baseline, centered on Wavefront proxy handoff and hosted Tanzu defaults instead of a generic vendor-direct OTLP exporter claim
  • Kubernetes companion follow-through is now shipped as the latest platform-neutral collector-first slice on top of the shared OpenTelemetry baseline, centered on in-cluster collector wiring and generic cluster resource defaults instead of a vendor-specific managed exporter claim
  • downstream Cloudflare and custom-provider companion authoring guidance is now shipped under #120, keeping the remaining Cloudflare follow-through honest about the current Worker-native export model instead of promising a generic first-party host-side sink
  • Grafana Cloud companion follow-through is now shipped as the latest explicit OTLP endpoint/auth-header slice on top of the shared OpenTelemetry baseline, centered on direct Grafana Cloud endpoint wiring plus access-policy-backed auth headers while keeping the collector-first path available
  • New Relic companion follow-through is now shipped as the latest explicit native OTLP endpoint/api-key slice on top of the shared OpenTelemetry baseline, centered on region-aware endpoint defaults plus required api-key header guidance while keeping the collector-first path available
  • exporter wiring, auth, resource-attribute conventions, and hosted-runtime defaults that stay inside companion packages instead of Cephalon.Engine
  • documentation, validation, and planning guidance that make the supported targets, deployment assumptions, and downstream companion-package authoring path explicit
  • a clear package split whenever different clouds or platforms need distinct companion packs instead of one overloaded abstraction

Exit criteria:

  • self-hosted collector and runtime defaults can be enabled on top of the shipped OTLP baseline without modifying Cephalon.Engine or Cephalon.Abstractions
  • supported cloud and platform integrations can be enabled without modifying Cephalon.Engine or Cephalon.Abstractions
  • downstream developer-authored provider packages can reuse the shared telemetry contract without modifying Cephalon.Engine or Cephalon.Abstractions
  • the shared ILogger pipeline and cloud-neutral OTLP baseline remain intact
  • docs, validation flows, and planning metadata make the supported targets explicit

Phase 7: External adoption and operator readiness

Section titled “Phase 7: External adoption and operator readiness”

Status: substantially complete

Goal: let external teams install, validate, package, and run Cephalon outside this repository without repo-only tribal knowledge.

Current baseline already in place:

  • Cephalon.Cli already ships a working new command plus hosted-reference-doc workflows
  • Cephalon.TemplatePack already ships installable blueprint and module starters
  • sample apps and a reference module package already prove the main blueprint and package-authoring shapes inside the repo
  • package manifests, trust policy, package policy, and /engine/packages already expose the runtime package-loading contract
  • runtime status, health, diagnostics, runtime-story, and telemetry-export surfaces already give operators a truthful runtime answer once a host is running
  • release validation, package publishing, and template/tool install smoke coverage already existed before phase 7, even though they started from a Windows-first baseline

Deliverables:

  • cross-platform script, shell, and CI parity for the repo-native validation, packaging, and install surfaces
  • a first-run adoption path with an environment-doctor or equivalent self-check flow in Cephalon.Cli
  • a machine-readable deployment-mode support contract that keeps trim / Native AOT / single-file support claims aligned with readiness validation, package-publishing guidance, and human-facing docs before Cephalon widens its external support matrix
  • a generated-app bootstrap verification follow-through that reuses cephalon doctor to validate a scaffolded app root, package-source baseline, host project, and publish profile before the first restore, run, publish, or deployment replay
  • an end-to-end external module-package lifecycle prove-out that exercises publish, trust, load, and runtime introspection outside the repo-local assembly path
  • a containerized local runtime/operations sample path that proves health, config-loading, and telemetry/export handoff under Docker Desktop or WSL-friendly environments without pushing Docker-specific behavior into the engine core
  • generated-app bootstrap assets and package-source guidance that let a freshly scaffolded app restore, build, and run from a seeded local feed or a replaced external source without rediscovering Cephalon’s package assumptions
  • a generated-app published-output baseline that proves scaffolded hosts can be folder-published, started from published artifacts, and inspected through the shipped runtime, health, and docs surfaces
  • a generated-app Windows Service deployment baseline that proves scaffolded hosts carry an installable self-hosted Windows service-manager shape after publish without inventing platform-specific packaging from scratch
  • a generated-app IIS deployment baseline that proves scaffolded hosts carry a hosted Windows site/app-pool shape after publish without inventing platform-specific ASP.NET Core Module packaging from scratch
  • a generated-app Azure App Service deployment baseline that proves scaffolded hosts carry a hosted Azure ZIP-deploy shape after publish without inventing cloud-specific packaging from scratch
  • a generated-app container-image publishing baseline that proves scaffolded hosts carry a provider-neutral build/tag/push image shape from the generated Dockerfile and app root without inventing a registry workflow from scratch
  • a generated-app Azure Container Apps deployment baseline that proves scaffolded hosts carry a hosted Azure source-deploy shape from the generated Dockerfile and app root without inventing cloud-specific container-deploy packaging from scratch
  • a generated-app Kubernetes deployment baseline that proves scaffolded hosts carry a platform-neutral manifest/apply shape from the generated Dockerfile and app root without inventing a second cluster-deploy packaging workflow from scratch
  • a generated-app Linux systemd deployment baseline that proves scaffolded hosts carry an installable self-hosted service-manager shape after publish without inventing platform-specific packaging from scratch

Current status as of April 29, 2026:

  • ENG-033 is implemented: repo-native validation, package publishing, and reference-doc flows now run through pwsh-friendly scripts with Windows and Ubuntu CI legs
  • ENG-034 is implemented: Cephalon.Cli now ships cephalon doctor, and the repo now has a dedicated getting-started path plus aligned help/readme guidance
  • ENG-035 is implemented: published module .nupkg artifacts can now be staged through cephalon package stage, loaded from out-of-tree package directories, and verified through trust/policy/runtime-introspection coverage
  • ENG-036 is implemented: the modular monolith sample now ships a Dockerfile, compose stack, collector config, optional package-directory override, container-runtime docs, and an optional smoke script that verifies Docker Desktop / WSL-friendly runtime startup plus /health/* and /engine/* replay
  • ENG-037 is implemented: cephalon new and the shipped dotnet new app starters now emit NuGet.config plus a local package-feed placeholder, the shared prerelease package-version baseline is aligned again, and a real generated app has been verified through scaffold -> package publish -> build -> Docker compose smoke
  • ENG-038 is implemented: scaffolded hosts and shipped dotnet new app starters now emit Properties/PublishProfiles/CephalonFolder.pubxml, publish into deterministic artifacts/publish/<ProjectName>/ output, and are verified through a real scaffold -> package publish -> folder publish -> run published output smoke path
  • ENG-039 is implemented: scaffolded hosts and shipped dotnet new app starters now emit Linux systemd deployment assets under deploy/linux/systemd/, and those generated units are verified through a real scaffold -> package publish -> folder publish -> WSL systemd-analyze verify smoke path
  • ENG-040 is implemented: scaffolded hosts and shipped dotnet new app starters now emit Windows Service deployment assets under deploy/windows-service/, and those generated install/remove scripts are verified through a real scaffold -> package publish -> folder publish -> install-preview smoke path against published output
  • ENG-041 is implemented: scaffolded hosts and shipped dotnet new app starters now emit IIS deployment assets under deploy/iis/, and those generated install/remove scripts plus the SDK-generated ANCM web.config are verified through a real scaffold -> package publish -> folder publish -> install-preview smoke path against published output
  • ENG-042 is implemented: scaffolded hosts and shipped dotnet new app starters now emit Azure App Service deployment assets under deploy/azure-app-service/, and those generated ZIP packaging and deploy-preview scripts are verified through a real scaffold -> package publish -> folder publish -> run-from-package smoke path against the current Azure CLI contract
  • ENG-043 is implemented: scaffolded hosts and shipped dotnet new app starters now emit Azure Container Apps deployment assets under deploy/azure-container-apps/, and those generated source-deploy scripts are verified through a real scaffold -> package publish -> local Docker build -> deploy-preview smoke path against the current Azure CLI contract
  • ENG-044 is implemented: scaffolded hosts and shipped dotnet new app starters now emit Kubernetes deployment assets under deploy/kubernetes/, and those generated manifest/apply scripts are verified through a real scaffold -> package publish -> local Docker build -> kubectl kustomize preview smoke path against the generated app root
  • ENG-045 is implemented: scaffolded hosts and shipped dotnet new app starters now emit container-image publishing assets under deploy/container-image/, and those generated build/tag/push scripts are verified through a real scaffold -> package publish -> local Docker build -> local-registry push smoke path against the generated app root
  • ENG-209 is implemented: Cephalon.Cli now extends cephalon doctor with --app-root <path> so a freshly scaffolded app can truthfully validate its .slnx, Directory.Packages.props baseline, NuGet.config cephalon source and package-source mapping, seeded local feed or external source, generated host project, and CephalonFolder.pubxml profile from one command path before restore, run, publish, or deployment work
  • ENG-213 is implemented: cephalon doctor --app-root <path> now also validates the generated Dockerfile plus the shipped container-image, Azure Container Apps, and Kubernetes deployment assets and checks that the Dockerfile SDK/runtime base-image tags still align with the generated host target framework baseline before container deployment work
  • ENG-214 is implemented: cephalon doctor --app-root <path> now also validates the shipped Windows Service, IIS, Azure App Service, and Linux systemd deployment assets and checks that those generated published-output baselines still align with the current host identity before self-hosted or hosted deployment work
  • ENG-215 is implemented: cephalon doctor --app-root <path> now also validates the shipped compose.yaml and otel-collector-config.yaml local orchestration assets, checks that the generated compose baseline still aligns with the Dockerfile plus OTLP collector handoff, and checks that the collector config still exposes health_check, otlp/http on 4318, and the debug-exporter pipelines before local docker compose up --build work
  • ENG-216 is implemented: cephalon doctor --app-root <path> now also validates the generated Configurations/AddOpenApi.json and Configurations/AddReferenceDocs.json documentation-surface assets, checks that the generated OpenAPI title and hosted reference-doc settings stay explicit in split project config, and keeps /scalar plus optional hosted reference-doc posture visible before teams rely on those routes
  • ENG-217 is implemented: cephalon doctor --app-root <path> now also validates the generated Configurations/AddEngine.*.json assets plus Configurations/Observability/Development.json, checks that the scaffolded app-model, engine-feature, observability, localization, and development Serilog split-config baselines stay explicit, and keeps split project configuration posture visible before teams rely on those generated runtime, docs, or telemetry defaults
  • ENG-218 is implemented: cephalon doctor --app-root <path> now also validates the scaffolded Program.cs bootstrap source plus the generated host-project PackageReference set and Configurations/**/*.json copy/publish baseline, checks that explicit AddCephalonProjectConfigurations plus MapCephalon wiring stay visible, and keeps host startup plus build/publish bootstrap posture visible before teams rely on edited startup code
  • ENG-219 is implemented: cephalon doctor --app-root <path> now also validates the generated test project plus scaffolded Architecture/CompositionSmokeTests.cs and Features/*BehaviorSpecifications.cs placeholders, checks that starter composition smoke plus Given/When/Then seams stay explicit, and keeps the generated test harness truthful before teams replace those placeholders with real specs
  • ENG-220 is implemented: cephalon doctor --app-root <path> now also validates the generated root README.md, Configurations/README.md, and deployment README.md guidance assets, checks that generated package-source, split-config, publish, deployment, and local-orchestration instructions still align with the current app root, and keeps human-facing generated guidance visible before teams follow the scaffolded docs literally
  • ENG-221 is implemented: cephalon doctor --app-root <path> now also validates the generated .cephalon/packages/README.md guidance asset, checks that local package-feed seeding plus shared-feed replacement instructions still align with the current app root, and keeps generated package-bootstrap guidance visible before teams seed packages or replace the cephalon source
  • ENG-223 is implemented: cephalon doctor --app-root <path> now also validates the generated Kubernetes manifest content in deploy/kubernetes/kustomization.yaml, deploy/kubernetes/namespace.yaml, deploy/kubernetes/deployment.yaml, and deploy/kubernetes/service.yaml, checks that namespace, labels, image placeholder, env, probe, and ClusterIP service seams still align with the current app root, and keeps platform-neutral Kubernetes manifest posture visible before teams rely on those shipped manifests
  • ENG-224 is implemented: cephalon doctor --app-root <path> now also validates the generated deploy/windows-service/remove-service.ps1, deploy/iis/remove-site.ps1, and deploy/linux/systemd/<App>.env assets, checks that Windows Service stop/delete flow, IIS site/app-pool teardown flow, and Linux systemd environment plus telemetry override hints still align with the current app root, and keeps teardown plus service-manager environment posture visible before teams rely on those operational assets
  • ENG-225 is implemented: the repo now ships scripts/validate-generated-app-adoption.ps1 as the scenario-driven external cold-start replay baseline, publish-package-artifacts.ps1 now preserves an existing output README.md so generated local package-feed guidance survives package refreshes, and the install -> doctor -> scaffold -> seed local packages -> doctor —app-root -> restore -> build -> run -> route-probe loop is now provable from a temporary workspace outside the repository without relying on hidden repo context
  • ENG-226 is implemented: the repo now ships scripts/validate-template-pack-adoption.ps1 as the external cold-start template-pack parity replay baseline, cephalon doctor now honors CEPHALON_DOCTOR_TEMPLATE_HIVE so isolated custom-hive installs can be validated from the same first-run command path, and cephalon doctor --app-root <path> now accepts template-pack project-root starters in addition to the CLI scaffold layout while preserving the same bootstrap, deployment-asset, and route-readiness truth
  • ENG-227 is implemented: the repo now ships scripts/validate-out-of-tree-package-adoption.ps1 as the external out-of-tree package parity replay baseline, proving the temporary-feed install -> cephalon doctor -> scaffold -> seed local packages -> pack reference module -> cephalon package stage -> patch Engine:Discovery:PackageDirectories plus Engine:PackagePolicy and Engine:Trust -> doctor —app-root -> restore -> build -> run -> staged-package route and runtime-surface probe loop from a temporary workspace outside the repository without relying on hidden repo context
  • ENG-228 is implemented: the repo now ships scripts/validate-signed-package-governance.ps1 as the higher-assurance external package governance replay baseline, proving the temporary-feed install -> cephalon doctor -> scaffold -> seed local packages -> repack Cephalon.ReferenceModule.Operations with a deterministic detached signature -> cephalon package stage -> patch Engine:Discovery:PackageDirectories plus stricter Engine:PackagePolicy and Engine:Trust:TrustedSignaturePublicKeys -> doctor —app-root -> restore -> build -> run -> signed-package runtime and route probes, followed by a tampered-package denial path when signature verification is required
  • ENG-229 is implemented: the repo now ships scripts/validate-signed-package-certificate-chain-governance.ps1 as the matching external certificate-chain trust replay baseline, scripts/validate-signed-package-governance.ps1 now supports certificate-chain trust mode alongside public-key trust, and the same external-adoption lane now proves Engine:Trust:TrustedSignatureCertificates plus Engine:Trust:TrustedSignatureCertificateAuthorities surface trusted-certificate-chain verification plus certificateThumbprint truth while still denying tampered signed packages
  • ENG-230 is implemented: the repo now ships the April 2026 engine surface maturity reset through docs/engine-surface-maturity-audit.md, refreshed roadmap/backlog/governance language, and explicit M0 through M4 plus ownership-mode vocabulary so descriptor-first work, runtime truth, and execution-owning surfaces stop reading like the same maturity level
  • ENG-231 is implemented: Cephalon.Eventing now ships host-agnostic managed subscription execution contracts and execution-binding vocabulary, while Cephalon.Eventing.Wolverine can opt into EnableSubscriptionExecution on top of EnableDispatchLoop so the repo now has one truthful wolverine-managed event-subscription execution lane with fixed-delay retry scheduling, eventing.subscribe, runtime-bound event-subscriptions metadata, richer wolverine-adapter runtime state, regenerated reference docs, and focused composition/hosting/tooling validation
  • ENG-232 is implemented: Cephalon.Agentics now ships a host-agnostic IAgentToolDispatcher plus executor, policy, observer, run-report, and run-catalog contracts so registered tools can execute through one Cephalon-managed lane, report approval/denial/success/failure state into the agent-tools technology surface, and prove the flow through the showcase sample without claiming broader autonomous planning, memory, retry, queue, or AI-provider orchestration ownership
  • ENG-269 is implemented: agentics dispatcher command contracts now live in Cephalon.Abstractions.Agentics, Cephalon.Agentics remains the implementation owner for descriptor resolution, policy decisions, executor invocation, observer notifications, and run-state reporting, and ASP.NET Core now exposes POST /engine/agent-tools/{toolId}/runs so operators can trigger one bounded managed tool run without referencing the agentics implementation package - issue #778
  • ENG-280 is implemented: Cephalon.Agentics now adds bounded process-local retry settings for the managed dispatcher lane, reports retry-scheduled observations plus final run state, and projects non-durable retry policy metadata through agentics.execution, agent-tools, /engine/agent-tool-runs/retry-pending, and snapshot.AgentToolRuns while durable retry queues, autonomous planning, memory persistence, distributed scheduling, and provider-specific AI orchestration remain later package-owned work - issue #789
  • ENG-281 is implemented: Cephalon.Agentics now adds opt-in bounded process-local duplicate-completed suppression for managed tool runs, reports duplicate completed toolId + runId executions as skipped, exposes DuplicateCompleted plus /engine/agent-tool-runs/idempotency-duplicates, and projects non-durable idempotency policy metadata through agentics.execution, agent-tools, and reported.* while durable inboxes, cross-node exactly-once delivery, durable retry queues, autonomous planning, memory persistence, distributed scheduling, and provider-specific AI orchestration remain later package-owned work - issue #790
  • ENG-282 is implemented: Cephalon.Agentics now exposes approval-required and terminal-failure run posture as operator filters through /engine/agent-tool-runs/approval-required and /engine/agent-tool-runs/terminal-failures, adds AgentToolRunState.TerminalFailure, and projects terminalFailure metadata through agent-tools while durable approval workflows, dead-letter systems, durable retry queues, autonomous planning, memory persistence, distributed scheduling, and provider-specific AI orchestration remain later package-owned work - issue #791
  • ENG-233 is implemented: Cephalon.Retrieval now ships host-agnostic IKnowledgeDocumentProvider, IKnowledgeIndexer, IKnowledgeQueryEngine, and an implementation of the abstraction-level IKnowledgeIndexCatalog contract so registered knowledge collections can build one Cephalon-managed lexical index, execute bounded queries, report freshness plus query fingerprints into the knowledge-collections technology surface, and prove the flow through the showcase sample without claiming vector databases, embeddings, durable or distributed search, rerankers, provider-specific semantic search, or distributed scheduler coordination ownership
  • ENG-267 is implemented: retrieval index-state read contracts now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval remains the implementation owner for document-provider ingestion, lexical indexing, bounded query execution, freshness calculation, and in-memory state, and ASP.NET Core now exposes /engine/knowledge-indexes plus snapshot.KnowledgeIndexes so operator tooling can read collection posture without referencing the retrieval implementation package - issue #776
  • ENG-268 is implemented: retrieval indexing command contracts now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval remains the implementation owner for provider ingestion, lexical indexing, freshness calculation, and index-state updates, and ASP.NET Core now exposes POST /engine/knowledge-indexes/{collectionId}/reindex so operators can remediate a collection without referencing the retrieval implementation package - issue #777
  • ENG-270 is implemented: Cephalon.Retrieval now registers an opt-in generic-host background reindex scheduler when ingestion and EnableBackgroundReindexing are enabled, runs over all registered collections or configured collection ids through the same IKnowledgeIndexer, records safe scheduler metadata, and projects retrieval.background-reindexing plus backgroundReindexing* metadata while distributed scheduler coordination, vector search, durable indexes, and provider-specific search adapters remain later package-owned work - issue #779
  • ENG-283 is implemented: retrieval query command contracts now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval remains the implementation owner for bounded lexical query execution and runtime query observations, and ASP.NET Core now exposes POST /engine/knowledge-indexes/{collectionId}/queries so operators can query a collection without referencing the retrieval implementation package - issue #792
  • ENG-271 is implemented: Cephalon.Eventing now registers an opt-in direct in-process event publisher when EnableInProcessSubscriptionExecution is enabled and matching IEventSubscriptionExecutor services exist, executes subscriptions through the same IEventPublisher contract, reports subscription runtime state, and projects cephalon-managed, in-process-direct, retryPolicy = none truth through capabilities, event-publishers, event-subscriptions, /engine/event-subscription-readiness, and snapshot.EventSubscriptionExecutionReadiness while durable broker dispatch, inbox/idempotency, retry queues, and distributed scheduling remain later package-owned work - issue #780
  • ENG-272 is implemented: event-publication command contracts now live in Cephalon.Abstractions.Data, Cephalon.Eventing owns the bounded IEventPublicationDispatcher implementation over the active IEventPublisher, ASP.NET Core exposes POST /engine/event-publications, and publication metadata now flows into in-process subscription execution state while durable broker dispatch, inbox/idempotency, retry queues, distributed scheduling, and provider-specific inbound consumption remain later package-owned work - issue #781
  • ENG-273 is implemented: Cephalon.Eventing now adds bounded process-local retry settings for the opt-in in-process subscription execution lane, retries transient executor failures inline before returning the publication result, records retry-scheduled observations plus final runtime state, and projects bounded-in-process, max-attempt, delay, non-durable, and process-local retry metadata through capabilities, bindings, event-publishers, and event-subscriptions while durable broker retries, inbox/idempotency, retry queues, distributed scheduling, and provider-specific inbound consumption remain later package-owned work - issue #782
  • ENG-274 is implemented: Cephalon.Eventing now adds opt-in bounded process-local duplicate-completed execution suppression for the in-process subscription lane, records successful subscriptionId + publicationId executions in memory for the configured retention window, reports duplicates as skipped, and projects non-durable idempotency policy/key/scope/retention metadata through capabilities, bindings, event-publishers, event-subscriptions, and reported.* while durable inbox ownership, cross-node exactly-once delivery, broker deduplication, durable retry queues, distributed scheduling, and provider-specific inbound consumption remain later package-owned work - issue #783
  • ENG-275 is implemented: event-publication runtime-state contracts now live in Cephalon.Abstractions.Data, Cephalon.Eventing reports the latest publication state through IEventPublicationRuntimeCatalog, in-process publication observations distinguish succeeded, failed, and skipped local execution posture with subscription counters, outbox-backed publication observations report accepted staged handoff with downstream dispatch still separate, and ASP.NET Core exposes /engine/event-publications/runtime* plus snapshot.EventPublicationStates without claiming durable broker delivery - issue #784
  • ENG-276 is implemented: Cephalon.Eventing.Wolverine now adds SubscriptionMaxAttempts, projects bounded-fixed-delay retry policy plus max-attempt, delay, durability, and scope metadata through eventing.subscribe, binding metadata, event-subscriptions, and the wolverine-adapter runtime surface, and reports terminal failed state with retryExhausted = true / terminalFailure = true when the provider-managed subscription retry budget is exhausted - issue #785
  • ENG-277 is implemented: Cephalon.Eventing.Wolverine now adds DispatchMaxAttempts, projects bounded-fixed-delay dispatch retry policy plus max-attempt, delay, dispatch-store durability, and provider-managed scope metadata through eventing.wolverine.dispatch, dispatch runtime descriptors, dispatch reports, and the wolverine-adapter runtime surface, and reports terminal failed state with retryExhausted = true / terminalFailure = true when no-destination or publish failures exhaust the dispatch retry budget - issue #786
  • ENG-234 through ENG-261 plus ENG-284 through ENG-312 are implemented: Cephalon.MultiTenancy now stays narrow around tenant resolution and governance-boundary truth while Cephalon.MultiTenancy.Governance owns the concrete companion proofs for membership catalog/evaluation, opt-in durable local membership storage, invitation catalog/validation, opt-in durable local invitation storage, host-agnostic invitation delivery dispatch/run-state/outcome persistence over registered sender extensions, opt-in local invitation delivery retry storage plus bounded retry execution, process-local retry execution coordination, and opt-in automatic background retry scheduling/run-state, host-agnostic invitation delivery status reconciliation over provider or receiver observations, opt-in durable local delivery-status observation storage, host-driven tenant-administration workflow commands over membership and invitation stores, declared domain-ownership catalog/validation, opt-in durable local domain-ownership storage, in-process domain-ownership verification workflow transitions, domain proof challenge issuance, domain proof publication planning, HTTP file proof publication state for host adapters, domain proof evaluation over reported evidence, bounded on-demand HTTP file proof collection, configured on-demand DNS TXT proof collection, domain proof verification runner orchestration, bounded on-demand proof polling, opt-in automatic background proof polling scheduling/run-state, approval/remediation action catalog/decision, in-process approval/remediation action workflow transitions, and opt-in durable local action storage, while Cephalon.MultiTenancy.Governance.AspNetCore owns optional HTTP proof serving plus the fail-closed tenant-administration command endpoint, fail-closed invitation delivery dispatch endpoint, fail-closed normalized invitation delivery-status callback endpoint, opt-in provider-neutral callback signature verification, bounded process-local signed-callback replay protection, and bounded observation-history reads over the host-agnostic observation store, Cephalon.MultiTenancy.Governance.HttpDelivery owns optional generic HTTP webhook invitation sending plus provider-neutral idempotency headers, HMAC request signing, and bounded in-process retry/backoff, Cephalon.MultiTenancy.Governance.SmtpDelivery owns optional SMTP relay invitation sending with templated messages, deterministic message ids, safe context headers/metadata, and a replaceable client seam, Cephalon.MultiTenancy.Governance.SendGridDelivery owns optional SendGrid Mail Send API invitation sending with templated payloads, safe context headers/custom arguments/categories, sandbox-mode validation, provider message-id capture, diagnostics 4560-4561, and a replaceable client seam, Cephalon.MultiTenancy.Governance.MailgunDelivery owns optional Mailgun Messages API invitation sending with templated multipart payloads, safe variables/headers, test-mode posture, provider message-id capture, diagnostics 4566-4567, and a replaceable client seam, Cephalon.MultiTenancy.Governance.AmazonSesDelivery owns optional Amazon SES v2 invitation sending with templated SendEmail payloads, safe region/configuration-set/status/message-id/tag/recipient metadata, diagnostics 4576-4577, and a replaceable AWS SDK handoff seam, Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore owns optional Amazon SES over SNS callback translation, opt-in SNS signature verification, bounded process-local SNS replay protection, observation-store-backed SNS message-id idempotency, opt-in verified SNS subscription confirmation, and opt-in verified SNS unsubscribe-confirmation observation with diagnostics 4578-4584 and the tenant-invitation-delivery-amazon-ses-status-callbacks runtime surface, Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery owns optional Microsoft Graph sendMail invitation sending with templated JSON payloads, safe x-* headers, Graph request-id capture, diagnostics 4572-4573, and replaceable client/token-provider seams, and Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery.AzureIdentity owns optional Azure Identity access-token acquisition for the Graph sender with diagnostics 4574-4575 without claiming actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond state transitions, distributed or provider-backed governance storage, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, distributed retry queues, cross-node retry leases, provider-specific or distributed callback inboxes, cross-node callback replay protection, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, identity-provider synchronization, public onboarding, or tenant-admin UI/backoffice flows - issues #793, #800, #801, #802, #803, #804, #805, #806, #807, #808, #809, #810, #814, #819, #820, #821, #822, #823, #824, #825, #826, #827
  • ENG-296 is implemented: Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore now also owns optional SendGrid signed Event Webhook verification with ECDSA-SHA256 over timestamp plus exact raw request body bytes, rejects invalid signed callbacks before parsing or reconciliation, records safe signature metadata, emits diagnostics 4563, and keeps durable inboxes, distributed replay, provider polling, non-SendGrid callback translation/signature semantics, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores outside this proof - issue #811
  • ENG-297 is implemented: Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore now also owns bounded process-local replay protection for verified SendGrid signed Event Webhook callbacks, rejects duplicate safe signature fingerprints with 409 before reconciliation, records safe replay metadata, emits diagnostics 4564, and keeps durable inboxes, distributed replay ledgers, provider polling, cross-node exactly-once delivery, non-SendGrid callback translation/signature semantics, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores outside this proof - issue #812
  • ENG-298 is implemented: Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore now also owns observation-store-backed SendGrid event-id idempotency, skips duplicate translated sendgrid:{sg_event_id} observations before reconciliation, records safe idempotency metadata, emits diagnostics 4565, and keeps durable callback inboxes, distributed replay/event-id ledgers, provider polling, cross-node exactly-once delivery, non-SendGrid callback translation/signature semantics, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores outside this proof - issue #813
  • ENG-299 is implemented: Cephalon.MultiTenancy.Governance.MailgunDelivery now owns optional Mailgun Messages API invitation sending with templated multipart payloads, safe context variables/headers, test mode, provider JSON id capture, diagnostics 4566-4567, and a replaceable Mailgun client seam while Mailgun callback translation later shipped through ENG-300, Mailgun signed-webhook verification later shipped through ENG-301, Mailgun replay-token rejection later shipped through ENG-302, and Mailgun event-id idempotency later shipped through ENG-303; provider polling, durable callback inboxes, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this sender proof - issue #814
  • ENG-300 is implemented: Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore now owns optional Mailgun webhook callback translation into the existing delivery-status reconciler with bounded JSON parsing, user-variable context extraction, provider message-id normalization, safe callback metadata, diagnostics 4568, and the tenant-invitation-delivery-mailgun-status-callbacks runtime surface while Mailgun signed-webhook verification later shipped through ENG-301, replay-token rejection later shipped through ENG-302, and event-id idempotency later shipped through ENG-303; durable callback inboxes, provider polling, exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #815
  • ENG-301 is implemented: Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore can now require Mailgun HMAC-SHA256 signed webhook verification over timestamp + token, supports signature.parent-signature for subaccount events when enabled, rejects invalid or stale signed callbacks before reconciliation, records only safe signature posture metadata, emits diagnostics 4569, and reports cephalon-managed signature verification ownership through tenant-invitation-delivery-mailgun-status-callbacks while Mailgun replay-token rejection later shipped through ENG-302 and event-id idempotency later shipped through ENG-303; durable callback inboxes, provider polling, exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #816
  • ENG-302 is implemented: Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore can now reject duplicate verified Mailgun signed webhook tokens inside a bounded process-local replay window, stores only SHA-256 token fingerprints, returns 409 before reconciliation for duplicate tokens, records safe replay posture metadata, emits diagnostics 4570, and reports cephalon-managed replay ownership through tenant-invitation-delivery-mailgun-status-callbacks while durable callback inboxes, distributed replay/event-id ledgers, provider polling, exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #817
  • ENG-303 is implemented: Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore now also owns observation-store-backed Mailgun event-id idempotency, skips duplicate translated mailgun:{event-data.id} observations before reconciliation, returns DuplicateEvents plus per-event duplicate-skipped outcomes, records safe event-id idempotency metadata, emits diagnostics 4571, and reports cephalon-managed idempotency ownership through tenant-invitation-delivery-mailgun-status-callbacks while durable callback inboxes, distributed replay/event-id ledgers, provider polling, exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #818
  • ENG-304 is implemented: Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery now owns optional Microsoft Graph sendMail invitation sending with templated JSON payloads, safe custom x-* internet message headers, Graph request-id metadata capture, diagnostics 4572-4573, a replaceable Graph HTTP client seam, and a replaceable access-token provider seam while Microsoft Entra app registration, permission consent, mailbox access policy, token-provider implementation before ENG-305, delivery completion after Graph accepts sendMail, Graph change notifications, provider polling, durable callback inboxes, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #819
  • ENG-305 is implemented: Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery.AzureIdentity now owns optional Azure Identity access-token acquisition for the Microsoft Graph invitation sender with configuration/code-first DefaultAzureCredential setup, explicit TokenCredential injection, Graph scope selection, tenant id, managed-identity client id, authority-host selection, safe credential toggles, diagnostics 4574-4575, and replacement of the sender token-provider seam while Microsoft Entra app registration, Graph Mail.Send permission consent, mailbox access policy, credential lifecycle policy beyond the selected Azure credential, Graph delivery completion/notifications, provider polling, durable callback inboxes, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #820
  • ENG-306 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery now owns optional Amazon SES v2 invitation sending with templated SendEmail payloads, optional configuration set/reply-to/tags, safe region/configuration-set/status/message-id/tag/recipient metadata capture, diagnostics 4576-4577, and a replaceable AWS SDK client seam while AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox exit, configuration-set event destination setup, provider polling, durable callback inboxes, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof; Amazon SES over SNS callback translation later shipped through ENG-307 - issue #821
  • ENG-307 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now owns optional Amazon SES over SNS callback translation into the existing delivery-status reconciler with bounded SNS Notification parsing, SES event JSON unwrapping, Cephalon mail.tags context extraction, SES mail.messageId correlation, safe callback metadata, diagnostics 4578, and the tenant-invitation-delivery-amazon-ses-status-callbacks runtime surface while SNS signature verification, process-local SNS replay protection, SNS message-id idempotency, verified SNS subscription confirmation, and verified SNS unsubscribe-confirmation observation later shipped through ENG-308, ENG-309, ENG-310, ENG-311, and ENG-312; SES event-destination setup, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #822
  • ENG-308 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now owns opt-in Amazon SNS signature verification before Amazon SES callback translation, requires signature version 2 and allowed TopicArn values by default, validates HTTPS Amazon SNS signing-certificate URLs, supports pinned PEM certificates for controlled tests, validates certificate chain posture by default, records safe signature metadata, emits diagnostics 4579, and projects signature-version/topic/certificate policy through tenant-invitation-delivery-amazon-ses-status-callbacks while process-local SNS replay protection, SNS message-id idempotency, verified SNS subscription confirmation, and verified SNS unsubscribe-confirmation observation later shipped through ENG-309, ENG-310, ENG-311, and ENG-312; SES event-destination setup, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #823
  • ENG-309 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now owns bounded process-local replay protection for verified SNS-wrapped Amazon SES callbacks, stores safe fingerprints derived from verified SNS TopicArn plus MessageId, rejects duplicate verified callbacks with 409 Conflict before reconciliation, records safe replay metadata, emits diagnostics 4580, and projects replay policy/key/scope/durability/retention/cache posture through tenant-invitation-delivery-amazon-ses-status-callbacks while SNS message-id idempotency, verified SNS subscription confirmation, and verified SNS unsubscribe-confirmation observation later shipped through ENG-310, ENG-311, and ENG-312; SES event-destination setup, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #824
  • ENG-310 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now owns observation-store-backed SNS message-id idempotency for Amazon SES callbacks, checks normalized amazon-ses-sns:{MessageId} observation ids before reconciliation, skips duplicate translated events with duplicate-skipped outcomes and aggregate duplicateEvents, records safe idempotency metadata, emits diagnostics 4581, and projects message-id idempotency policy/key/scope/store-durability posture through tenant-invitation-delivery-amazon-ses-status-callbacks while verified SNS subscription confirmation and verified SNS unsubscribe-confirmation observation later shipped through ENG-311 and ENG-312; SES event-destination setup, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #825
  • ENG-311 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now owns opt-in verified SNS subscription confirmation for Amazon SES callbacks through EnableSnsSubscriptionConfirmation, SnsSubscriptionConfirmationTimeoutSeconds, and IAmazonSesSnsSubscriptionConfirmationClient, confirms only verified SubscriptionConfirmation envelopes from allowed topics, validates trusted HTTPS Amazon SNS SubscribeURL values, returns subscription-confirmation aggregate fields, emits diagnostics 4582-4583, and projects confirmation ownership/policy/timeout posture through tenant-invitation-delivery-amazon-ses-status-callbacks while verified SNS unsubscribe-confirmation observation later shipped through ENG-312; SNS topic/subscription creation, SES event-destination setup, automatic resubscribe/restore, subscription lifecycle governance, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #826
  • ENG-312 is implemented: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now owns opt-in verified SNS unsubscribe-confirmation observation for Amazon SES callbacks through EnableSnsUnsubscribeConfirmationObservation, observes only verified UnsubscribeConfirmation envelopes from allowed topics, validates trusted HTTPS Amazon SNS SubscribeURL values, never invokes SubscribeURL, returns unsubscribe-confirmation aggregate fields, emits diagnostic 4584, and projects unsubscribe-confirmation ownership/action/SubscribeURL policy through tenant-invitation-delivery-amazon-ses-status-callbacks while SNS topic/subscription creation, SES event-destination setup, automatic resubscribe/restore, subscription lifecycle governance, durable callback inboxes, distributed replay/event-id ledgers, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain outside this proof - issue #827
  • the planned phase-7 baseline plus the generated-app bootstrap, generated-app bootstrap verification, starter test-harness verification, published-output, local orchestration, container-image publishing, Windows/Linux self-hosted deployment follow-through, hosted Windows IIS path, hosted Azure App Service plus Azure Container Apps paths, platform-neutral Kubernetes path, external cold-start adoption replay, template-pack parity replay, out-of-tree package parity replay, detached-signature governance replay, and certificate-chain trust replay are now in place, so the next adoption work can stay scenario-driven and focus on broader external provenance or distribution follow-through instead of filling a known install/run/deploy gap

Exit criteria:

  • a team can install the CLI or template pack, scaffold an app or module, and validate its environment on Windows or Linux-class shells without custom repo knowledge
  • a team can rerun cephalon doctor --app-root <path> against a freshly scaffolded app and get one truthful answer for generated-app bootstrap readiness, generated Program.cs plus host-project PackageReference and Configurations/**/*.json baseline posture, generated test-project plus CompositionSmokeTests.cs and BehaviorSpecifications.cs starter-harness posture, generated guidance docs plus local package-feed guidance posture, generated self-hosted and hosted deployment assets plus generated container deployment-asset, Dockerfile-baseline, and local orchestration compose or collector posture, and copy/paste-ready restore or run next steps
  • the repo-native validation and packaging flow no longer depends on Windows-only shell assumptions
  • an out-of-tree Cephalon package can be published, trusted, loaded, and inspected through the shipped runtime surfaces
  • at least one adoption-quality sample host can be run through a documented containerized path that preserves the current /engine/*, /health/*, and telemetry behaviors
  • a freshly scaffolded Cephalon app can restore, build, and take the documented container path after seeding or repointing the supported cephalon package source
  • a freshly scaffolded Cephalon app can publish to a deterministic folder profile and run from published output with the expected runtime, health, and docs surfaces
  • a freshly scaffolded Cephalon app can carry a documented Windows Service baseline with generated install assets and a verified install-preview path against published output
  • a freshly scaffolded Cephalon app can carry a documented IIS site/app-pool baseline with generated install assets, the expected ANCM web.config, and a verified install-preview path against published output
  • a freshly scaffolded Cephalon app can carry a documented Azure App Service ZIP-deploy baseline with generated packaging assets, WEBSITE_RUN_FROM_PACKAGE guidance, and a verified Azure CLI preview path against published output
  • a freshly scaffolded Cephalon app can carry a documented container-image publishing baseline with generated build/tag/push assets, provider-neutral registry guidance, and a verified local-registry smoke path against the generated app root
  • a freshly scaffolded Cephalon app can carry a documented Azure Container Apps source-deploy baseline with generated Docker assets, az containerapp up --source guidance, and a verified Azure CLI preview path against the generated app root
  • a freshly scaffolded Cephalon app can carry a documented Kubernetes deployment baseline with generated manifest/apply assets, kubectl kustomize guidance, and a verified preview path against the generated app root
  • a freshly scaffolded Cephalon app can carry a documented Linux systemd service baseline with generated install assets and a verified self-hosted service-manager path
  • a team can replay the external cold-start adoption path from a temporary workspace by installing Cephalon.Cli from a package feed, running cephalon doctor, scaffolding a fresh app, seeding the generated ./.cephalon/packages feed without losing the generated README guidance, rerunning cephalon doctor --app-root <path>, restoring, building, running, and probing the generated host

Phase 8: Configurable application architecture and runtime primitives

Section titled “Phase 8: Configurable application architecture and runtime primitives”

Status: in progress

Goal: let consumer apps keep one Cephalon codebase while switching architecture, data, messaging, identity, tenancy, and audit choices through configuration and additive companion packs instead of host rewrites or blueprint explosion.

Product principle for this phase: Cephalon should lower ceremony for consumer apps by absorbing repetitive plumbing, declarations, and host wiring so teams write less framework code and focus more of their codebase on business logic.

Current baseline already in place:

  • configuration-driven Blueprint, Patterns, Technologies, and Transports through the Engine section
  • built-in blueprints for ModularMonolith, ModularVerticalSlice, and Microservice
  • shipped pattern and technology catalogs plus additive technology companion-package wiring
  • scaffold plans that already imply Application/Domain/Infrastructure plus Commands/Queries/Policies/Strategies starter shapes
  • runtime snapshot, runtime-story, diagnostics, technology-surface, and package-introspection endpoints that later packs can extend without inventing a second control plane
  • an observability companion-package ecosystem that already proves provider-specific follow-through can stay outside Cephalon.Engine and Cephalon.Abstractions
  • ENG-046 landed locally: phase-8 pattern and technology ids now exist with alias-aware resolution in the shipped catalogs
  • ENG-047 landed locally: structured Engine:Data, Engine:Identity, Engine:Tenancy, Engine:Audit, and Engine:Messaging settings now flow into the resolved app profile with phase-8 prerequisite validation
  • ENG-048 landed locally: Cephalon.Abstractions now carries host-agnostic data, authorization, tenancy, audit, and id contracts with XML comments, package-surface coverage, and reference-doc validation, and Cephalon.Engine now exposes merged projection, inbox, outbox, and authorization-policy catalogs through /engine/projections, /engine/inboxes, /engine/outboxes, /engine/authorization-policies, and /engine/snapshot
  • ENG-049 is in progress locally: Cephalon.Data now provides runtime-neutral IReadStore / IWriteStore dispatching backed by command/query handlers, Cephalon.Data.EntityFramework now registers single-context or split read/write Entity Framework Core DbContext roles plus opt-in Entity Framework-backed inbox and outbox baselines and optional Sfid.EntityFramework conventions, Cephalon.Engine now surfaces additive inbox/outbox catalogs through IInboxCatalog, IOutboxCatalog, /engine/inboxes, /engine/outboxes, and /engine/snapshot, the Entity Framework pack now contributes staged-only outbox-producers entries plus application-managed inbox-stores entries under event-driven-integration when that technology is active, the Entity Framework outbox now also exposes an adapter-neutral IEventDispatchStore with durable dispatch_attempt_count / dispatched_at_utc / next_attempt_at_utc follow-through for later shipped companion adapters, and Cephalon.Ids.Sfid wraps the official Sfid.Net generator behind IIdGenerator plus the official generator interface with Engine:Data:Ids:Sfid topology support while richer projection persistence/runtime surfaces remain open
  • ENG-050 is now in progress locally: Cephalon.Eventing exposes public EventPublication, IEventPublisher, EventDispatchItem, and IEventDispatchStore contracts, registers an outbox-backed staged publication path only when a real IOutbox exists, surfaces that truth through eventing.publish and the event-publishers runtime surface, now also exposes declared subscription descriptors through eventing.subscriptions and the event-subscriptions runtime surface, can report when an application-managed inbox store is available, can link declared subscriptions to hosted-execution descriptors plus execution graphs and runtime-story state when modules publish that metadata, now also carries application-managed subscription runtime-state/reporting plus stable diagnostics conventions for those outcomes, now also carries application-managed outbox-dispatch runtime-state/reporting through IEventDispatchRuntimeReporter / IEventDispatchRuntimeCatalog with reported.* metadata on the new event-dispatches surface, now projects configured dispatch-runtime descriptor metadata through those outbox-facing entries, now has a runtime-neutral bridge for later adapter-owned dispatch loops without claiming that the pack itself already owns broker dispatch, retries, or handler execution, and now ships an official Cephalon.Eventing.Wolverine adapter slice that can run as a thin host-wiring baseline with dispatchBridge = consumer-managed or as an opt-in wolverine-managed durable staged-dispatch loop on top of IEventDispatchStore while its adapter surface aggregates latest outcome and retry/runtime totals for operator views and its pack-specific diagnostics convention first exposed stable 4300-4303 loop event ids through /engine/diagnostics before later follow-through extended that range
  • ENG-051 is now in progress locally: Cephalon.Identity now exists as the first host-agnostic identity companion pack with config-driven IdentityRuntimeOptions, declarative IdentityPolicyMetadataKeys, a default metadata-driven IAuthorizationEvaluator, a truthful identity-authorization technology surface under identity-access, and stable 4400-4401 diagnostics-catalog entries for allow/deny outcomes, and Cephalon.Identity.AspNetCore now exists as the follow-through host adapter with config-driven Engine:Identity:AspNetCore options plus a REST-only RequireCephalonAuthorization(...) helper that maps ClaimsPrincipal, route values, and request metadata into the shared Cephalon authorization contracts without polluting the core
  • ENG-051 follow-through now also honors ASP.NET Core challenge/forbid behavior when the host or endpoint metadata already declares authentication schemes, including the low-ceremony WithCephalonAuthenticationSchemes(...) endpoint helper, which keeps scheme ownership with the consumer host while letting Cephalon return ecosystem-native 401 and 403 outcomes instead of always forcing problem-details fallbacks
  • ENG-051 follow-through now also respects AllowAnonymous endpoint metadata inside protected route groups so consumer apps can keep standard ASP.NET Core public-route semantics without forking Cephalon authorization wiring for the rest of the group
  • ENG-051 follow-through now also has direct request-factory coverage for custom claim-type mapping, subject-id fallback behavior, and optional claim/route/query/header projection flags so the low-ceremony ASP.NET Core adapter keeps its config-driven authorization-request shaping truthful beyond the happy-path hosting tests
  • ENG-051 follow-through now also honors EnableDefaultEvaluator and EnableRuntimeSurface truthfully, so the host-agnostic pack can opt out of the built-in evaluator without turning protected endpoints into missing-service failures and can suppress the identity-authorization runtime surface entirely when a consumer wants that pack-level telemetry quiet
  • ENG-051 follow-through now also covers controller/action boundaries through a public [RequireCephalonAuthorization] attribute and projects an identity-aspnetcore runtime surface so /engine/technology-surfaces can report how many ASP.NET Core endpoints are protected, which Cephalon policy ids are active, and where AllowAnonymous overrides still exist across minimal APIs and MVC-style controllers
  • ENG-051 follow-through now also bridges authenticated ASP.NET Core principal data into the ambient audit actor contract when Cephalon.Audit is active and the host has not registered a custom accessor, which keeps the low-ceremony actor path in the host adapter instead of leaking ASP.NET Core concerns into the host-agnostic audit pack
  • ENG-052 is now in progress locally: Cephalon.MultiTenancy now exists as the first host-agnostic tenancy companion pack with config-driven MultiTenancyRuntimeOptions, AddMultiTenancy(...), a built-in configuration-driven ITenantResolver, an ambient ITenantContextAccessor, a truthful tenant-resolution surface under multi-tenancy, stable 4500-4502 diagnostics-catalog entries, and explicit miss semantics that keep tenant-id, tenant-key, and host-name mismatches from silently defaulting into another tenant while still allowing hosts to disable the built-in resolver cleanly
  • ENG-052 is also now proving the narrow audit slice locally: Cephalon.Audit exists as the first host-agnostic audit companion pack with AddAudit(...), AuditRuntimeOptions, AuditMetadataKeys, ambient actor access, a default recorder, stable 4600-4601 diagnostics-catalog entries, and a dedicated IAuditStoreCatalog surfaced through /engine/audit-stores and /engine/snapshot
  • ENG-052 follow-through now also honors AuditRuntimeOptions.EnableInMemoryWriter / Engine:Audit:EnableInMemoryWriter end to end across service-collection, ASP.NET Core, and Worker host paths, and the runtime audit-store catalog now stays aligned with that choice instead of pretending the memory-backed store is active when it is not
  • ENG-052 follow-through now also preserves additive consumer audit-store contributions when AddAudit() is active, so /engine/audit-stores and /engine/snapshot keep showing custom/runtime-provided stores even when the built-in audit-default store is disabled or absent
  • ENG-052 follow-through now also keeps audit actor resolution low ceremony in ASP.NET Core hosts by consuming the authenticated principal through the identity adapter when available, while runtime surfaces still answer truthfully whether that bridge is active, merely available, or absent and custom audit actor accessors remain authoritative
  • ENG-053 is now in progress locally: Cephalon.Scaffolding and Cephalon.Cli now emit canonical phase-8 ids plus structured Engine:Data, Engine:Identity, Engine:Tenancy, Engine:Audit, and Engine:Messaging sections, generated hosts now centralize the common low-ceremony phase-8 pack wiring, generated tests now start with architecture smoke checks plus per-feature behavior specifications, Cephalon.TemplatePack starter apps now carry a narrow Sfid plus Audit baseline with the same canonical config shape, and starter sample hosts now mirror that same baseline with hosting coverage that locks their /engine/app-model answers
  • ENG-055 is now in progress locally: scripts/validate-phase8-conventions.ps1 now gives phase 8 a named validation replay across settings/profile truth, runtime catalogs and surfaces, relational data plus Sfid, eventing plus Wolverine, identity/tenancy/audit, ASP.NET Core adapter follow-through, starter generation, package-surface truth, reference-doc generation, and adoption-doc alignment, scripts/validate-release.ps1 now runs that focused suite by default, Cephalon.Benchmarks now carries explicit phase-8 composition, runtime-lifecycle, and scaffolding baselines with refreshed guardrail thresholds from the current BenchmarkDotNet output, and the repo-native release-validation path is green again after compatibility-truth and discovery-scope fixes in the reference-module and test harness assets
  • phase-8 messaging direction is now explicit: Cephalon.Eventing.Wolverine is the first shipped optional companion proof, MassTransit is the tracked-later adapter candidate after the engine-owned contract and that proof are validated strongly enough, and MediatR, LiteBus, NServiceBus, and SlimMessageBus remain consumer-owned coexistence choices unless a later bridge or adapter package is deliberately shipped

Milestone outline:

  • M1 Taxonomy and contracts: freeze blueprint vs pattern vs technology vs companion-pack semantics; add structured Engine:Data, Engine:Identity, Engine:Tenancy, Engine:Audit, and Engine:Messaging sections; add host-agnostic contracts and runtime surfaces
  • M2 Data and messaging foundation: ship a relational-first golden path through Cephalon.Data, Cephalon.Data.EntityFramework, CQRS read/write split, projections, outbox, event runtime follow-through, optional Wolverine integration, and Cephalon.Ids.Sfid
  • M2 should use the official Sfid.Net and Sfid.EntityFramework packages for the id baseline instead of inventing a custom Cephalon-specific Snowflake implementation
  • M3 Identity, tenancy, and audit baseline: ship optional RBAC, ABAC, and policy-based authorization, multi-tenant runtime contracts plus tenant-aware audit/history surfaces, and keep ASP.NET Core-specific wiring in host adapters
  • M4 CLI, scaffolding, templates, and samples: align Cephalon.Cli, Cephalon.Scaffolding, Cephalon.TemplatePack, and adoption-quality samples with the same phase-8 config and package contract
  • M5 Provider-family and hybrid-runtime follow-through: expand beyond the relational-first baseline into explicit non-relational provider families plus additive HybridCloudRuntime, ServiceMeshIntegration, and ServerlessHosting follow-through only after the core contract is proven

Planned workstreams:

  • WS1 Engine core: taxonomy, structured settings, host-agnostic contracts, validation, runtime surfaces, and XML-commented public descriptors
  • WS2 Companion packs: data, eventing, identity, multi-tenancy, audit, Sfid, and optional third-party adapters that stay config-driven and observability-aware
  • WS3 CLI and scaffolding: generation, package hints, template defaults, and golden-path samples that mirror the same runtime semantics
  • Validation lane: cross-cutting review of benchmarks, test coverage, XML comments, runtime introspection, docs/reference-doc alignment, and over-claim risk before milestone closeout

Deliverables:

  • a canonical mapping for Hexagonal, Layered, CleanArchitecture, DDD, CQRS, Outbox, and EventSourcing as patterns instead of new blueprints
  • a canonical mapping for IdentityAccess, MultiTenancy, HybridCloudRuntime, ServiceMeshIntegration, and ServerlessHosting as additive technologies instead of engine-core rewrites
  • host-agnostic contracts for commands, queries, read/write stores, projections, outbox/inbox, authorization subjects/resources/policies, tenant context/resolution, audit entries, and id generation
  • a relational-first, Entity Framework-centered baseline that proves CQRS read/write split, projections, outbox handoff, and Sfid ids before broader provider expansion
  • event-driven runtime follow-through that upgrades the shipped event-channel surface into truthful declared-subscription plus staged-publishing, then fuller publisher/subscriber/runtime-answer semantics without breaking the current technology-pack split
  • optional identity/authorization, multi-tenancy, and audit companion packages that a consumer can turn on, turn off, or override through configuration
  • CLI/scaffolding/template/sample alignment with the same config sections, package hints, and scaffold plans
  • observability, diagnostics, and runtime-snapshot follow-through for every active phase-8 pack
  • benchmark, validation, docs, and reference-doc follow-through that keeps the shipped capability claims truthful as phase-8 packages land
  • a lower-ceremony consumer experience where common infrastructure, architecture, and runtime choices move into config, companion packs, and scaffold conventions instead of repeated host/bootstrap code

Exit criteria:

  • a consumer app can keep one Cephalon codebase and change supported architecture, data, security, and runtime choices through configuration plus companion-pack selection rather than a host rewrite
  • Cephalon.Abstractions stays host-agnostic and public contracts remain XML-commented enough for supported reference-doc publishing
  • the first golden path works end to end for relational Entity Framework plus CQRS plus outbox plus event-driven integration plus configurable identity/authorization plus multi-tenancy plus audit plus Sfid
  • CLI generation, scaffold output, templates, samples, and runtime introspection tell the same story for the phase-8 baseline
  • benchmark guardrails, docs, and public XML comments stay aligned with each shipped phase-8 contract instead of lagging implementation
  • non-relational provider breadth plus hybrid-cloud, service-mesh, and serverless follow-through remain explicit later slices until the golden path proves the contract
  • consumer apps can keep framework ceremony low by declaring architecture/runtime choices once through configuration and package selection while concentrating hand-written code on business logic, domain rules, and use-case behavior

Current planning note as of April 8, 2026:

  • ENG-046, ENG-047, and ENG-048 should freeze the phase-8 taxonomy, settings, and contracts before workstream-specific implementation names drift
  • ENG-049 and ENG-050 are now actively proving the relational-first data and eventing baseline before broader provider expansion; the next truth gate is moving from application-managed publication/subscription reporting into a truthful optional companion execution path without over-claiming pack-owned dispatch behavior or turning one adapter into an engine requirement
  • ENG-051 and ENG-052 should layer identity/authorization plus multi-tenancy/audit on top of the frozen data/messaging contract
  • ENG-051 is now proving the host-agnostic evaluator/runtime-surface baseline plus the first ASP.NET Core adapter slice, and the next follow-through should deepen scheme/challenge alignment plus broader host-integration coverage without polluting the core
  • ENG-052 is now proving the configuration-driven tenant-resolution/runtime-surface baseline plus the first narrow Cephalon.Audit recording slice, and the next follow-through should deepen audit storage and adapter options instead of overloading the tenancy pack with membership, domain-onboarding, or data-isolation claims too early
  • ENG-053 is now proving the TDD/BDD-friendly starter-test convention on top of the frozen ids/config/package baseline, and the next follow-through should focus on any remaining sample/template docs parity plus starter polish instead of re-deciding the starter semantics
  • ENG-055 is now establishing the named validation replay, refreshed benchmark guardrails, and docs/runtime-truth guard for the shipped phase-8 baseline, while ENG-056 should continue the broader docs, XML-comment, and reference-doc closeout before phase 8 claims broad readiness
  • ENG-056 is now done locally: the checked-in docs/reference/ bundle has been regenerated for the current phase-8 assembly set, the tooling test lane now guards bundle drift by comparing the checked-in output against the current Cephalon.ReferenceDocs generator after normalizing volatile timestamps, and the top-level adoption docs plus blueprint sample READMEs now describe the shipped phase-8 starter baseline truthfully
  • ENG-054 Track 1 (non-relational provider families) is now complete: all 9 provider families (MongoDB, Redis, Neo4j, Cassandra, ClickHouse, Elasticsearch, OpenSearch, Qdrant, NATS) shipped across Sprints 25–31 with 18 companion packages (9 data + 9 event-sourcing), 648/648 tests green; hybrid-runtime, service-mesh, and serverless expansion remain later until explicit adoption cases
  • ENG-057 event-sourcing follow-through is now complete: Cephalon.EventSourcing core contracts plus 10 provider implementations (EntityFramework + 9 non-relational) are shipped with IBehaviorContext.EventStore wiring through ENG-058 M6

Status: done

Goal: introduce a unified application-behavior model that composes domain operations across transports, patterns, and execution strategies without requiring per-transport or per-pattern rewrites.

Delivered:

  • ENG-058 M1 ABT foundation: IAppBehavior, IBehaviorContext, BehaviorDispatcher, BehaviorExecutionSlot, CompatibilityMatrix, 6 compatibility rules (ABT-001 through ABT-006), hosting integration — 499/499 tests (Sprint 20)
  • ENG-058 M2 HTTP Transport Pack: 7 HTTP bindings (rest, jsonrpc, graphql, graphql-sse, graphql-ws, sse, ws), LazyTransportBinding — 516/516 tests (Sprint 21)
  • ENG-058 M3 Messaging Transport Pack: InMemory, RabbitMQ, Kafka bindings; M2 CTS leak fix — 527/527 tests (Sprint 22)
  • ENG-058 M4 Pattern Execution Strategies: 5 strategies (cqrs, event-driven, saga-step, process-manager, direct), ISagaStateStore, IProcessCheckpointStore, FrozenDictionary registry, IBehaviorContext.CorrelationId, IProcessCompletion — 575/575 tests (Sprint 23)
  • ENG-058 M5 Source Generator: BehaviorSourceGenerator (IIncrementalGenerator + DiagnosticAnalyzer), ABT0010–ABT0013 diagnostics, BehaviorRegistrationHints.g.cs — 584/584 tests (Sprint 24)
  • ENG-058 M6 Runtime Integration: BehaviorRuntimeContributor, IBehaviorAdvisory system, IBehaviorContext.EventStore wiring, BehaviorDiagnostics EventId 5100-5109 — 592/592 tests (Sprint 24)
  • ENG-058-T30 behavior-aware REST endpoint helper follow-through: MapBehaviorRestGroup(...), BehaviorRestEndpointGroup.MapBehaviorGet/Post/Put/Patch/Delete(...), module-major versioned operation-name defaults, XML-comment-backed OpenAPI enrichment, DefaultBehaviorContext event-store DI wiring for HTTP execution, and showcase cart route deduplication — composition HTTP tests 13/13 plus showcase hosting tests 33/33 (Sprint 31)
  • ENG-058-T31 behavior REST OpenAPI summary/description split follow-through: behavior XML <summary> now maps to the OpenAPI operation summary while XML <remarks> maps to the OpenAPI operation description, avoiding duplicate Scalar text and locking the generated cart endpoint contract through showcase hosting coverage — composition HTTP tests 13/13 plus showcase hosting tests 34/34 (Sprint 31)
  • ENG-058-T32 behavior REST OpenAPI document-version follow-through: BehaviorRestEndpointGroup.ApiVersion(...) now assigns behavior-shaped REST endpoints to named OpenAPI documents, operation-name versioning now falls back to the module major only when no explicit API version is supplied, OpenApi:Documents plus optional OpenApi:DefaultDocument now drive ASP.NET Core OpenAPI/Scalar document registration, showcase cart routing now opts into v1, and hosting coverage now locks /openapi/v2.json plus /scalar/v2 behavior — composition HTTP tests 14/14 plus hosting tests 235/235 (Sprint 31)
  • ENG-058-T33 behavior REST OpenAPI versioned-config canonicalization: OpenApi:EnabledVersions plus OpenApi:DefaultVersion is now the canonical host config for versioned API documents, legacy OpenApi:Documents and OpenApi:DefaultDocument remain available for backward compatibility or custom named docs, the global OpenApi:Version info override now only applies to single-document hosts so multi-document metadata stays truthful, and the showcase sample plus authoring docs now demonstrate the numeric version contract — composition HTTP tests 14/14 plus hosting tests 235/235 (Sprint 31)
  • ENG-058-T34 Scalar multi-document doc-link follow-through: /scalar now redirects to the configured default versioned document while /scalar/v1, /scalar/v2, and similar paths remain available as pinned doc links; hosting coverage and authoring docs now lock that behavior — composition HTTP tests 14/14 plus targeted hosting tests 2/2 (Sprint 31)
  • ENG-058-T35 canonical REST/doc version alignment: .ApiVersion(major) now prefixes behavior-owned REST routes with /v{major} so host-mounted /api surfaces line up with the selected OpenAPI document, the showcase sample now exposes versioned REST routes under /api/v1/..., Scalar document selection rewrites back to canonical /scalar/v1 and /scalar/v2 links, and hosting/composition coverage locks the aligned contract — composition HTTP tests 14/14 plus targeted hosting tests 3/3 plus showcase hosting tests 34/34 (Sprint 31)
  • ENG-058-T36 configurable docs-route surfaces and module-major REST defaults: OpenApi:RoutePattern now controls the OpenAPI JSON route, OpenApi:Scalar:RoutePrefix now controls the Scalar UI base path, ApiRoutes:Prefixes:Rest now controls the built-in REST host prefix, and MapBehaviorRestGroup(...) now defaults its document/route version from the owning module descriptor major version while keeping .ApiVersion(...) as an explicit override. That round established the version-aligned REST/OpenAPI/Scalar contract before the broader transport-prefix unification landed — composition HTTP tests 14/14 plus hosting tests 4/4 plus showcase hosting tests 34/34 (Sprint 31)
  • ENG-058-T37 shared BehaviorApiSurface canonical routing for generic behavior HTTP bindings: BehaviorTopologyDescriptor now carries a transport-agnostic ApiSurface, BehaviorApiSurfaceDescriptor.CreateDefault(...) derives group/operation paths from the behavior id, WithApiSurface(...) plus the source generator keep fluent and compile-time topology aligned, and the JSON-RPC, GraphQL, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings now project canonical versioned routes from that shared surface. The earlier /behaviors/{id} compatibility aliases introduced in that round were later removed by ENG-058-T39 so the canonical versioned routes remain the only generic behavior HTTP surface — behavior API-surface tests 4/4 plus composition HTTP tests 14/14 (Sprint 31)
  • ENG-058-T38 canonical ApiRoutes:Prefixes defaults across built-in and generic HTTP transport surfaces: the canonical host config now defaults to Rest=/api, GraphQL=/graphql, JsonRpc=/json-rpc, Grpc=/grpc, Ws=/ws, Sse=/sse, GraphQLWs=/graphql-ws, and GraphQLSse=/graphql-sse; built-in transport mappers now read the same prefix contract as the generic behavior bindings; the showcase sample now consumes route prefixes from generated client config instead of hard-coded transport paths; and hosting/composition coverage now locks both default and override behavior — behavior API-surface + HTTP binding tests 22/22 plus targeted hosting tests 3/3 plus showcase hosting tests 34/34 (Sprint 31)
  • ENG-058-T39 remove generic /behaviors/{id} aliases from the behavior HTTP surface: canonical versioned routes are now the only generated behavior HTTP endpoints; BehaviorApiSurfaceRouteResolver no longer appends behavior-id compatibility aliases; the retired behavior-specific prefix/config aliases have been removed so the generic bindings read the same canonical ApiRoutes:Prefixes:* contract as the built-in host mappers; and XML comments, component docs, authoring guidance, and HTTP binding coverage now treat the canonical versioned routes as the single public contract — composition HTTP tests 24/24 (Sprint 31)
  • ENG-058-T40 public REST documentation separation plus tag-metadata follow-through: module-owned REST endpoints now own the published REST OpenAPI + Scalar surface, MapBehaviorRestGroup(...) can override tag names and descriptions explicitly, module XML <summary> plus <remarks> can now flow into top-level OpenAPI tag descriptions, and hosting/tooling coverage locks the public REST-vs-generic-adapter distinction — targeted hosting tests 3/3 plus package-surface tests 51/51 (Sprint 31)
  • ENG-058-T41 module-owned REST cleanup and removal of behavior-declared REST: http.rest is no longer a valid behavior allowlist or topology transport, ViaHttpRest(...) and the generic REST binding/config surface were removed, Engine:Behaviors now stays focused on auto-registration instead of per-behavior REST overrides, ApiRoutes:Prefixes:Rest = "" still mounts versioned module-owned REST routes at the root while null still falls back to /api, and docs/sourcegen/reference output now treat MapEndpoints(...) plus MapBehaviorRestGroup(...) as the only REST authoring path — behavior baseline + behavior source-generator + hosting + tooling coverage (Sprint 31)
  • ENG-058-T42 attribute-only behavior baseline synthesis plus transport alias normalization: the runtime now synthesizes topology from [BehaviorAllowedPatterns] plus [BehaviorAllowedTransports] when exactly one pattern is declared and no explicit topology exists, ambiguous multi-pattern declarations fail fast with a clearer authoring error, http.grpc is accepted as an allowlist alias for canonical grpc, and composition/component-doc coverage now lock the attribute-only registration behavior for non-REST transports (Sprint 31)
  • ENG-058-T43 module-owned behavior authoring base classes and ownership validation: IBehaviorModuleBuilder, IBehaviorOwnerModule, and OwnedBehaviorRegistration now make explicit module-owned behaviors a first-class engine contract, BehaviorModuleBase and RestBehaviorModuleBase now give authors a cleaner module API than implementing multiple interfaces directly, engine composition now validates duplicate ownership and preserves owned topology when auto-registration is enabled, REST helper mapping now rejects another module’s owned behavior, and docs/reference output now publish the new ownership-first authoring path — behavior baseline tests 47/47 plus hosting tests 3/3 plus tooling tests 72/72 (Sprint 31)
  • ENG-058-T43 explicit module-owned behavior authoring model: IBehaviorOwnerModule, IBehaviorModuleBuilder, and OwnedBehaviorRegistration now make module-owned behavior registration explicit; BehaviorModuleBase and RestBehaviorModuleBase now give developers a low-ceremony authoring path for process-only and REST-exposed behavior modules; engine composition now validates duplicate ownership across modules; and behavior-backed REST mapping now rejects modules that try to expose behaviors owned by another module — behavior baseline tests 46/46 plus REST OpenAPI hosting tests 3/3 plus package-surface tests 51/51 (Sprint 31)
  • ENG-058-T43 module-owned behavior authoring baseline: IBehaviorOwnerModule, IBehaviorModuleBuilder, and OwnedBehaviorRegistration now make module-owned behavior declarations explicit, BehaviorModuleBase and RestBehaviorModuleBase give authors a higher-level authoring path, engine build now rejects duplicate owners, and REST helper mapping now rejects cross-module behavior exposure when ownership is explicit (Sprint 31)
  • ENG-058-T44 single-surface REST behavior-module DSL and opt-in auto-registration fallback: RestBehaviorModuleBase now centers authoring on ConfigureRestBehaviors(IRestBehaviorModuleBuilder behaviors) so public REST routes and internal-only behavior ownership can live in one module method, IRestBehaviorModuleBuilder plus IRestBehaviorEndpointGroupBuilder now make Group(...).MapGet/MapPost/... imply ownership automatically while Internal<TBehavior>() covers internal-only or custom/manual-route behaviors, MapAdditionalEndpoints(...) remains the advanced escape hatch for raw Minimal API work, Engine:Behaviors:AutoRegister now defaults to false so module ownership is the primary path and assembly scanning is an opt-in fallback, and showcase/reference-doc/component coverage now all align with that authoring model — behavior owner + baseline tests 48/48 plus REST OpenAPI + showcase hosting tests 37/37 plus package-surface tests 51/51 (Sprint 31)
  • ENG-058-T46 transport-neutral behavior results plus optional REST result envelopes: Cephalon.Abstractions now ships BehaviorResult<T>, IBehaviorResult, BehaviorResultStatus, and BehaviorFaultSeverity so behaviors can return structured expected outcomes without forcing HTTP envelopes into the core contract, explicit module-owned behaviors now fall back to direct topology when no extra topology metadata is supplied, ASP.NET Core now exposes ResultModel<T>, ResultModelError, and ResultModelErrorDetail as the optional REST wire envelope behind ApiRoutes:ResultEnvelope:Enabled, REST failures now use an errors collection so validation and other multi-reason outcomes can return more than one structured item, module-owned REST can wrap both raw TOut and BehaviorResult<T> results without forcing transport-specific envelopes back into the behavior contract, and module-owned REST OpenAPI now publishes wrapped success schemas without duplicating error properties on 2xx responses — behavior result + baseline tests 61/61 plus REST OpenAPI hosting tests 2/2 plus package-surface tests 51/51 (Sprint 31)
  • ENG-058-T47 plural REST error envelopes and multi-fault projection follow-through: the optional REST ResultModelError contract now uses an errors collection instead of a singular error object, BehaviorRestResponseMapper now projects BehaviorFault.InnerFaults into multiple structured REST errors for validation and other multi-reason failures, ResultModelDocumentTransformer now treats errors as the canonical REST envelope property without carrying a legacy singular fallback, and hand-authored docs plus REST OpenAPI hosting coverage now lock the plural wire contract — REST OpenAPI hosting tests 5/5 plus package-surface tests 51/51 (Sprint 31)
  • ENG-058-T48 showcase AddToCartBehavior authoring example for BehaviorResult<T>: the cart sample now demonstrates transport-neutral expected outcomes directly in AddToCartBehavior, including multi-fault validation through BehaviorFault.InnerFaults, a conflict result when the cart is already checked out, showcase-host overrides that opt into the REST result envelope for focused tests, and module-authoring/component docs that now point to the cart sample as the concrete reference for BehaviorResult<T> plus REST errors projection — showcase hosting tests 36/36 (Sprint 31)
  • ENG-058-T49 concise no-payload BehaviorResult factories: BehaviorResultDescriptor plus implicit conversion into BehaviorResult<T> now let common async-return branches use BehaviorResult.Invalid(...), BehaviorResult.NotFound(...), BehaviorResult.Conflict(...), BehaviorResult.Forbidden(...), BehaviorResult.Unauthorized(...), and BehaviorResult.NoContent(...) without restating the payload type; sample/component docs now demonstrate the shorter authoring path, and the authoring guidance now spells out the one remaining Task.FromResult<BehaviorResult<TOut>>(...) inference edge case explicitly — behavior result tests 3/3 plus package-surface tests 51/51 plus clean-worktree REST OpenAPI hosting verification (Sprint 31)
  • ENG-058-T51 concise Result<T> / Result aliases for transport-neutral outcomes: Cephalon.Abstractions now prefers Result<T> plus Result.*(...) for new behavior authoring while keeping BehaviorResult<T> / BehaviorResult as compatibility aliases, ASP.NET Core REST/OpenAPI detection now recognizes both result families, and the component/module-authoring docs now point teams to the shorter authoring shape by default while still documenting the legacy alias path (Sprint 31)
  • ENG-058-T50 configurable documented REST response statuses plus default 500: OpenApi:BehaviorRest:DocumentedStatusCodes now controls which HTTP status codes Cephalon’s behavior-owned REST helpers publish into OpenAPI + Scalar, the default documented status set now includes 500, route-group defaults no longer force 400/404 when the host narrows the list, and hosting coverage now locks both the default 500 visibility and a custom filtered status-code list — REST OpenAPI hosting tests 6/6 (Sprint 31)
  • ENG-058-T52 Scalar version selector driven by the resolved document contract: the ASP.NET Core host now injects the resolved document-name list plus default document into the bundled Scalar configuration script, multi-version docs render a top-right selector that follows OpenApi:EnabledVersions / OpenApi:DefaultVersion, legacy custom document names still remain supported through the same selector path, and targeted hosting coverage now locks both the injected-script contract and canonical /scalar multi-version routing behavior — targeted hosting tests 2/2 (Sprint 36)
  • ENG-058-T53 host-level published-version allow-list semantics for OpenAPI + Scalar: modules and behaviors still declare candidate document versions through .ApiVersion(...) or module-major defaults, but OpenApi:EnabledVersions and legacy OpenApi:Documents now stay authoritative as the published-document allow-list, disabled defaults no longer expand that set, and targeted hosting coverage now locks the case where v1, v2, and v3 endpoints exist while the host publishes only v2 plus v3 — targeted hosting tests 3/3 (Sprint 36)
  • ENG-058-T54 Scalar toolbar-mounted version selector: the injected Scalar selector now mounts into the api-reference-toolbar header row instead of floating over the page actions when that toolbar host is available, while preserving the floating fallback for non-standard shells, and targeted hosting coverage now locks the new header-mount script contract so Configure/Share/Deploy stay unobscured — targeted hosting tests 2/2 (Sprint 36)
  • ENG-058-T55 REST endpoint authoring strategy and precedence model: the repo now records the long-term REST endpoint authoring recommendation in docs/architecture/rest-endpoint-authoring-strategy.md, keeps explicit module-owned REST as the canonical public path, defines future shorthand as projection-driven metadata instead of direct behavior-owned REST activation, and records the settled design rules in project memory so the next implementation slices can evolve from one stable design baseline (Sprint 36)
  • ENG-058-T56 normalized REST behavior projections beneath the module DSL: Cephalon.Behaviors.Http now compiles IRestBehaviorModuleBuilder authoring into an internal RestBehaviorModuleProjection contract with normalized route-group and endpoint descriptors, reuses that same compiled projection for both module ownership registration and endpoint materialization through RestBehaviorProjectionMaterializer, keeps the public REST DSL unchanged, and locks duplicate-behavior-id, explicit-topology, and projection-reuse semantics through targeted REST projection tests 5/5 (Sprint 36)
  • ENG-058-T57 resolved public REST endpoint runtime catalog and collision validation: Cephalon.Abstractions now exposes IRestEndpointRuntimeCatalog, IRestEndpointRuntimeRegistry, and RestEndpointRuntimeDescriptor; Cephalon.AspNetCore now publishes /engine/rest-endpoints, /engine/rest-endpoints/{restEndpointId}, and snapshot.RestEndpoints; the public REST host now fails fast when two resolved endpoints collide on the same HTTP method + route pattern; and targeted hosting plus package-surface coverage lock the shipped runtime answer — targeted hosting tests 7/7 plus package-surface tests 52/52 (Sprint 36)
  • ENG-058-T58 manual module-owned REST runtime-catalog follow-through: the ASP.NET Core host now materializes the public REST runtime catalog from final route endpoints so plain IRestModule / IEndpointModule routes and RestBehaviorModuleBase.MapAdditionalEndpoints(...) behavior-helper routes join /engine/rest-endpoints and snapshot.RestEndpoints with sourceKind = manual, while manual-vs-DSL collisions now fail on the same HTTP method + route pattern baseline as projection-backed routes — targeted hosting tests 4/4 (Sprint 36)
  • ENG-058-T59 generic behavior transport route-version default follow-through: the ASP.NET Core host now keeps the generic JSON-RPC, GraphQL, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket adapter route segment driven by ApiRoutes:DefaultBehaviorDocumentName or the raw configured OpenApi:DefaultVersion instead of reusing the published OpenAPI allow-list default, so OpenApi:EnabledVersions and legacy OpenApi:Documents continue to govern only OpenAPI + Scalar publishing while the generic adapter routes remain independently versioned; explicit behavior-route overrides and the allow-list separation are now locked by composition HTTP binding tests 12/12 plus targeted hosting tests 2/2 (Sprint 36)
  • ENG-058-T60 ASP.NET Core hosting determinism and version-aware showcase route follow-through: the host now makes /engine/* Minimal API service binding explicit for .NET 10 parameter inference, strips transitive sample Configurations/** output from generic test projects, lets the showcase test harness point at the real sample content root, and keeps showcase orders-route assertions aligned with the owning module major version while the showcase transport projection keeps module-owned REST separate from generic behavior transport ids — targeted hosting tests 43/43 plus showcase hosting tests 60/60 (Sprint 36)
  • ENG-058-T61 metadata-only REST profile diagnostics and source-generated hints: Cephalon.Behaviors.Http now exposes BehaviorRestProfileAttribute, BehaviorRestMethod, and BehaviorRestProfileDescriptor as the metadata-only behavior-authored REST profile contract, Cephalon.Behaviors.SourceGen now validates those profiles through ABT0015 through ABT0018 and emits source-generated GetRestProfiles() hints, and the repo guidance now points authors at RestBehaviorModuleBase.ConfigureRestBehaviors(...) while keeping public REST module-owned — source-generator tests 16/16 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T62 explicit module-owned REST profile shorthand consumption: IRestBehaviorEndpointGroupBuilder.MapProfile<TBehavior>() now lets an owning module consume metadata-only behavior REST profiles through the same normalized RestBehaviorModuleBase projection pipeline, preferring source-generated GetRestProfiles() hints and falling back only to the explicitly targeted behavior type when generated hints are unavailable; profile metadata still contributes only method, relative pattern, and optional candidate API version while the owning module keeps the public prefix, tags, and published-document choice; conflicting profiled versions in one group now fail fast until the module resolves them explicitly; and /engine/rest-endpoints keeps sourceKind = module-dsl while exposing metadata.authoringStyle = behavior-module-profile for the shorthand path — targeted hosting tests 16/16 plus composition tests 5/5 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T63 explicit REST profile binding descriptors and runtime metadata: Cephalon.Behaviors.Http now exposes BehaviorRestBindingAttribute, BehaviorRestBindingDescriptor, and BehaviorRestBindingSource; BehaviorRestProfileDescriptor plus source-generated GetRestProfiles() hints now preserve explicit route/query/header/body binding plans; module-owned MapProfile<TBehavior>() now validates those bindings and composes requests in override mode so explicit bindings win while unbound route placeholders and request bodies can still fill remaining object properties deterministically; body conflicts against explicit non-body bindings now fail fast; and /engine/rest-endpoints now exposes additive metadata.bindingDescriptors for profile-driven module-owned REST endpoints — source-generator tests 17/17 plus targeted hosting tests 23/23 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T64 compile-time REST binding diagnostics and route-placeholder validation: Cephalon.Behaviors.SourceGen now rejects invalid BehaviorRestBindingAttribute metadata through ABT0019 through ABT0025, including unsupported binding sources, missing or duplicate input-property targets, scalar-input misuse, body bindings on non-body verbs, and route bindings that do not match placeholders declared in BehaviorRestProfileAttribute.RelativePattern; generated GetRestProfiles() output now resolves enum member names directly instead of depending on hard-coded numeric ordinals; and BehaviorRestProfileResolver now re-checks route-placeholder truth so MapProfile<TBehavior>() stays fail-fast even when runtime falls back to direct attribute metadata — source-generator tests 26/26 plus targeted hosting tests 26/26 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T65 typed REST endpoint runtime binding descriptors: Cephalon.Abstractions now exposes RestEndpointBindingDescriptor and RestEndpointBindingSource as the transport-owned runtime contract, RestEndpointRuntimeDescriptor plus snapshot.RestEndpoints now publish explicit profile-driven binding plans through the first-class BindingDescriptors property, Cephalon.Behaviors.Http now adapts behavior-authored binding metadata into that transport contract during module-owned REST materialization, and Cephalon.AspNetCore no longer duplicates the same plan into metadata.bindingDescriptors — targeted hosting tests 10/10 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T66 REST projection precedence and suppression visibility: Cephalon.Abstractions now exposes the REST endpoint candidate runtime contract, Cephalon.AspNetCore now publishes /engine/rest-endpoint-candidates plus snapshot.RestEndpointCandidates, and Cephalon.Behaviors.Http now resolves precedence across normalized module-owned REST projections so explicit module DSL mappings suppress lower-precedence MapProfile<TBehavior>() candidates for the same behavior by default while keeping published-versus-suppressed truth, winning candidate ids, and suppression reasons operator-visible — targeted hosting tests 28/28 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T67 low-code generated module-owned REST projections: IRestBehaviorEndpointGroupBuilder.MapGeneratedProfiles() plus MapGeneratedProfiles(string behaviorIdPrefix) now let an owning module publish every matching profiled behavior beneath one owned route group without restating each behavior individually, Cephalon.Behaviors.SourceGen now emits GetRestProfileBehaviorTypes() alongside GetRestProfiles() so the generated path can stay sourcegen-first, BehaviorRestProfileResolver now falls back only to a bounded scan of the explicit owning module assembly when generated type hints are unavailable, and the normalized candidate pipeline now keeps the effective behavior-projection precedence truthful as explicit module DSL > MapProfile<TBehavior>() > MapGeneratedProfiles(...) while publishing generated shorthand as metadata.authoringStyle = behavior-module-generated — source-generator tests 26/26 plus targeted hosting tests 33/33 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T68 REST endpoint governance and controlled config suppression: Cephalon.Abstractions now exposes IRestEndpointSuppressionRuntimeCatalog plus RestEndpointSuppressionDescriptor, RestEndpointCandidateRuntimeDescriptor now distinguishes config-governed suppression through SuppressedBySuppressionId, Cephalon.AspNetCore now binds RestApi:Suppressions and publishes /engine/rest-endpoint-suppressions plus snapshot.RestEndpointSuppressions, shorthand-suppression rules now fail fast when both Behaviors and Modules are missing, and Cephalon.Behaviors.Http now resolves overlapping matching rules deterministically before applying suppression ahead of precedence resolution so hosts can suppress MapProfile<TBehavior>() or MapGeneratedProfiles(...) candidates without rewriting route shape or overriding explicit module DSL/manual routes — targeted hosting tests 40/40 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T69 constrained shorthand API-version override governance: Cephalon.Abstractions now exposes IRestEndpointOverrideRuntimeCatalog plus RestEndpointOverrideDescriptor, RestEndpointCandidateRuntimeDescriptor now distinguishes config-governed shorthand version rewrites through AppliedOverrideId, Cephalon.AspNetCore now binds RestApi:Overrides and publishes /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, shorthand-override rules now fail fast when both Behaviors and Modules are missing or when ApiVersionMajor is missing/non-positive, and Cephalon.Behaviors.Http now resolves overlapping matching rules deterministically before retargeting descriptor-backed shorthand candidates to another effective API major version without overriding explicit module DSL/manual routes or shorthand groups that already declare .ApiVersion(...) explicitly — targeted hosting tests 49/49 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T70 constrained shorthand REST method override governance: RestEndpointOverrideDescriptor plus RestApi:Overrides now also support a shorthand HTTP Method action, shorthand-override rules now fail fast when they omit all override actions or declare an unsupported method, and Cephalon.Behaviors.Http now resolves matching shorthand overrides into an effective projection that ASP.NET Core materializes directly so mapped endpoints, /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides all agree on the same method-shaped runtime truth; explicit module DSL/manual routes remain authoritative, and shorthand groups with explicit .ApiVersion(...) still win for version while method overrides can still apply — REST projection/hosting tests 54/54 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T71 constrained shorthand REST pattern override governance: RestEndpointOverrideDescriptor plus RestApi:Overrides now also support a shorthand relative-route Pattern action, shorthand-override rules now fail fast when they omit all override actions or declare an invalid route pattern, and Cephalon.Behaviors.Http now resolves matching shorthand overrides into an effective projection that ASP.NET Core materializes directly so mapped endpoints, /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides all agree on the same pattern-shaped runtime truth; the current route-pattern slice allows only placeholder-preserving rewrites, so overrides can change static segments and reorder existing placeholders but fail fast when they add, remove, or rename placeholders; explicit module DSL/manual routes remain authoritative, and shorthand groups with explicit .ApiVersion(...) still win for version while pattern overrides can still apply — REST projection/hosting tests 61/61 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T72 constrained shorthand REST binding override governance: RestEndpointOverrideDescriptor plus RestApi:Overrides now also support explicit Bindings actions for descriptor-backed shorthand candidates, and Cephalon.Behaviors.Http now resolves those rules into one effective binding plan that ASP.NET Core materializes and revalidates so /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides stay aligned to the same binding-shaped runtime truth; binding overrides replace the shorthand candidate’s explicit binding plan while still letting unbound route placeholders and remaining request-body fields fill object properties deterministically, invalid effective plans such as body bindings on GET fail fast, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 65/65 (Sprint 36)
  • ENG-058-T73 constrained shorthand REST placeholder rename governance: Cephalon.Behaviors.Http now lets RestApi:Overrides rename shorthand route placeholders when the effective explicit route-binding plan covers the renamed placeholder set exactly, so ASP.NET Core can materialize /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides from one route-plus-binding truth without reopening inference drift; placeholder renames still fail fast when the effective route plan relies on inference instead of explicit route coverage, placeholder additions or removals remain later work, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 68/68 (Sprint 36)
  • ENG-058-T74 constrained shorthand REST placeholder removal governance: Cephalon.Behaviors.Http now lets RestApi:Overrides remove shorthand route placeholders when the original projection already exposes an explicit route-binding plan that covers the original placeholder set and the effective explicit binding plan keeps every affected originally route-bound property explicitly bound, so ASP.NET Core can materialize /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides from one route-plus-binding truth even when a route-bound value moves to query, header, or body; removal attempts still fail fast when the original route shape relied on inference or when affected properties lose explicit binding coverage, placeholder additions remain later work, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 73/73 (Sprint 36)
  • ENG-058-T75 constrained shorthand REST placeholder addition governance: Cephalon.Behaviors.Http now lets RestApi:Overrides add shorthand route placeholders when the effective explicit route-binding plan covers the full final placeholder set and every newly route-bound property was already explicitly bound in the original projection, so ASP.NET Core can materialize /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides from one route-plus-binding truth even when a value moves from query, header, or body into the route; addition attempts still fail fast when final route coverage is incomplete or when the override tries to promote an implicitly bound property into the public route, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 78/78 (Sprint 36)
  • ENG-058-T76 constrained shorthand REST implicit body-fallback route promotion: Cephalon.Behaviors.Http now lets RestApi:Overrides add shorthand route placeholders when the effective explicit route-binding plan covers the full final placeholder set and every newly route-bound property was either already explicitly bound in the original projection or, for POST/PUT/PATCH, already part of the original deterministic remaining-body fallback surface, so ASP.NET Core can keep /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides aligned to one route-plus-binding truth even when a value moves from implicit body fallback into the route; promotion attempts still fail fast when final route coverage is incomplete, when the source projection did not accept body input, or when the override would promote any other implicit property into the public route, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 82/82 (Sprint 36)
  • ENG-058-T77 shorthand REST governance selector expansion: RestApi:Suppressions and RestApi:Overrides can now refine descriptor-backed MapProfile<TBehavior>() and MapGeneratedProfiles(...) candidates with ApiVersionMajors, Methods, RelativePatterns, and RouteGroupPrefixes; those selectors match the original shorthand candidate shape before override actions are applied so hosts can govern one of several shorthand candidates that share the same behavior/module identity without losing runtime truth, specificity now also considers the expanded selector dimensions and narrower selector sets, the runtime suppression/override catalogs now expose the selector arrays directly, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 91/91 plus package-surface tests 53/53 (Sprint 36)
  • ENG-058-T78 shorthand REST original-projection runtime visibility: Cephalon.Abstractions now exposes RestEndpointCandidateProjectionDescriptor plus RestEndpointCandidateRuntimeDescriptor.OriginalProjection so operator tooling can compare original shorthand route, method, version, route-group prefix, relative pattern, and binding-plan truth against the final effective ProjectedEndpoint; Cephalon.Behaviors.Http now publishes that typed original projection before host overrides are applied while keeping ProjectedEndpoint as the final mapped answer; and /engine/rest-endpoint-candidates plus snapshot.RestEndpointCandidates now serialize both surfaces without hiding override-driven rewrites — REST projection/hosting tests 91/91 plus package-surface tests 53/53 (Sprint 36)
  • ENG-058-T79 merge-mode shorthand REST binding overrides: Cephalon.Abstractions now exposes RestEndpointOverrideBindingMode, RestEndpointOverrideDescriptor plus RestEndpointOverrideOptions now surface the typed binding-mode contract, Cephalon.AspNetCore now binds RestApi:Overrides:*:BindingMode, and Cephalon.Behaviors.Http now supports merge-explicit property-by-property binding patches in addition to the default full-plan replace-explicit behavior so hosts can retarget shorthand bindings without restating every untouched explicit descriptor; runtime override catalogs and snapshots now keep that merge-versus-replace governance truth visible, merge-explicit without Bindings now fails fast, and explicit module DSL/manual routes remain authoritative — REST projection/hosting tests 96/96 plus package-surface tests 53/53 (Sprint 36)
  • ENG-058-T80 grouped REST publication visibility catalog: Cephalon.Abstractions now exposes IRestEndpointPublicationGroupRuntimeCatalog plus RestEndpointPublicationGroupDescriptor, Cephalon.AspNetCore now publishes /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, and snapshot.RestEndpointPublicationGroups, and the host now groups the existing candidate-level truth per behavior so operators can inspect published candidates, precedence-suppressed candidates, governance-suppressed candidates, the winning precedence rank when one exists, and the ordered candidate set without manually joining several runtime surfaces — REST projection/hosting tests 41/41 plus package-surface tests 53/53 (Sprint 36)
  • ENG-058-T81 low-code inline module-owned REST authoring: Cephalon.Behaviors.Http now exposes RestBehaviorEngineBuilderExtensions.AddRestBehaviorModule<TMarker>() so hosts can register a real behavior-backed REST module without authoring a dedicated RestBehaviorModuleBase subclass; the helper still drives the same normalized projection/materialization/candidate/publication-group/governance pipeline as the class-based DSL, uses TMarker as the generated-profile source-assembly marker and as the reusable helper’s distinct module-type identity, keeps [AppBehavior] alone from publishing public REST, and now proves both MapProfile<TBehavior>() and MapGeneratedProfiles(...) through the inline path in hosting coverage — REST runtime/hosting tests 43/43 plus package-surface tests 54/54 (Sprint 36)
  • ENG-058-T82 bounded shorthand REST route-group-prefix overrides: Cephalon.Abstractions now extends the shorthand override contract with RouteGroupPrefix, Cephalon.AspNetCore now binds that action from RestApi:Overrides and keeps it visible through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, Cephalon.Behaviors.Http now validates that published group-prefix rewrites stay beneath the active REST root, contain no placeholders, and do not silently change effective API-version truth, and the ASP.NET Core materializer now splits effective shorthand route groups when only some candidates in one authored group are remapped so actual HTTP routes stay aligned with /engine/rest-endpoint-candidates, /engine/rest-endpoints, and the runtime snapshot — REST projection/hosting tests 111/111 (Sprint 36)
  • ENG-058-T83 merge-mode shorthand REST binding withdrawals: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor with RemovedBindingProperties, Cephalon.AspNetCore now binds RestApi:Overrides:*:RemovedBindingProperties and keeps the removed-property list visible through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, and Cephalon.Behaviors.Http now lets BindingMode = merge-explicit withdraw selected original explicit bindings without restating untouched descriptors so shorthand candidates can fall back to the remaining deterministic route/body contract without drifting away from /engine/rest-endpoint-candidates, /engine/rest-endpoints, or the runtime snapshot; removal-only rules now normalize to merge mode automatically, replace-explicit cannot pair with removals, one merge rule cannot both remove and override the same property, removal targets must already exist in the source shorthand explicit binding plan, and the runtime override catalog now keeps both binding mode and removed-property truth visible — REST projection/hosting tests 117/117 plus package-surface tests 54/54 (Sprint 36)
  • ENG-058-T84 low-code generated module-path helpers with explicit ownership: Cephalon.Behaviors.Http now exposes IRestBehaviorModuleBuilder.GroupFromBehaviorIdPrefix(string) so modules can derive /foo/bar from foo.bar for generated route groups without repeating both forms manually, and RestBehaviorEngineBuilderExtensions.AddGeneratedRestBehaviorModule<TMarker>() now wraps that same derivation for inline generated modules while still materializing a real module, feeding the same generated-profile projection/materialization/candidate/publication-group/governance pipeline, and failing fast when the behavior-id prefix cannot produce a deterministic route-group prefix — REST runtime/hosting tests 51/51 plus package-surface tests 55/55 (Sprint 36)
  • ENG-058-T85 stable shorthand candidate-id governance selectors: shorthand candidate ids now resolve from the original shorthand projection before host-level overrides are applied, RestApi:Suppressions and RestApi:Overrides now accept CandidateIds so a host can govern one exact shorthand candidate without composing a broader behavior/module rule first, runtime suppression/override catalogs plus the snapshot now surface those configured candidate ids directly, selector specificity now prefers candidate-targeted rules before broader selector matches, and ProjectedEndpoint continues to carry the effective mapped endpoint identity after override rewrites — REST projection tests 72/72 plus REST runtime/hosting tests 53/53 plus package-surface tests 56/56 (Sprint 36)
  • ENG-058-T86 shorthand candidate projected endpoint metadata alignment: Cephalon.Behaviors.Http now uses one shared operation-name/documentation convention path for both shorthand candidate resolution and final behavior-backed endpoint materialization, so ProjectedEndpoint in /engine/rest-endpoint-candidates now keeps endpoint name plus summary/description metadata aligned with /engine/rest-endpoints for MapProfile<TBehavior>() and MapGeneratedProfiles(...) candidates instead of leaving that operator-facing metadata incomplete until after ASP.NET Core materialization — REST projection tests 73/73 plus REST runtime/hosting tests 53/53 (Sprint 36)
  • ENG-058-T87 governance match visibility for shorthand REST candidates: Cephalon.Abstractions now extends RestEndpointCandidateRuntimeDescriptor with ordered MatchedSuppressionIds and MatchedOverrideIds, Cephalon.Behaviors.Http now preserves the full specificity-ordered suppression/override match trace for shorthand MapProfile<TBehavior>() and MapGeneratedProfiles(...) candidates while leaving SuppressedBySuppressionId and AppliedOverrideId as the selected-winner truth, and the runtime snapshot plus /engine/rest-endpoint-candidates now keep overlapping governance matches visible without changing the existing specificity or precedence model — GitHub issue #352; REST projection tests 73/73 plus REST runtime/hosting tests 53/53 plus package-surface tests 56/56 (Sprint 36)
  • ENG-058-T88 constrained shorthand REST implicit query-fallback route promotion: Cephalon.Behaviors.Http now lets RestApi:Overrides add shorthand route placeholders when the effective explicit route-binding plan covers the full final placeholder set and, for shorthand candidates with no explicit binding plan, every newly route-bound property was already part of the original implicit query-fallback surface, so shorthand GET-style profiles that still use the default query-plus-route merge path can promote selected values into the public route without losing runtime truth across /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpointOverrides; explicit-binding shorthand candidates remain on the stricter explicit-binding path, and promotion still fails fast when final route coverage is incomplete or when the override would promote any other implicit property into the public route — GitHub issue #353; REST projection tests 74/74 plus REST runtime/hosting tests 54/54 (Sprint 36)
  • ENG-058-T89 preserve implicit query fallback for partially explicitized shorthand REST overrides: Cephalon.Behaviors.Http now preserves the remaining implicit query-fallback surface when a shorthand candidate originally had no explicit binding plan and a host override adds only partial explicit bindings, so reshape-only overrides no longer silently drop untouched query-bound properties; /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot now keep that truth visible through additive metadata.bindingFallbackMode = preserve-source-implicit-fallback, while explicit-binding shorthand candidates remain on the stricter existing path — GitHub issue #354; REST projection tests 75/75 plus REST runtime/hosting tests 55/55 (Sprint 36)
  • ENG-058-T90 typed shorthand REST binding-fallback runtime contract: Cephalon.Abstractions now exposes RestEndpointBindingFallbackMode plus typed BindingFallbackMode properties on RestEndpointCandidateProjectionDescriptor and RestEndpointRuntimeDescriptor, Cephalon.Behaviors.Http plus Cephalon.AspNetCore now project the preserved implicit query-fallback answer onto the original shorthand projection and the effective published endpoint directly, and additive metadata.bindingFallbackMode = preserve-source-implicit-fallback remains compatibility-only metadata instead of the canonical runtime truth — GitHub issue #355; REST projection/runtime hosting tests 130/130 plus package-surface tests 57/57 (Sprint 36)
  • ENG-058-T91 published REST endpoint candidate provenance link: Cephalon.Abstractions now exposes nullable RestEndpointRuntimeDescriptor.CandidateId, Cephalon.Behaviors.Http now stamps published behavior-backed endpoints with the original candidate id during materialization, Cephalon.AspNetCore now projects that provenance through /engine/rest-endpoints plus snapshot.RestEndpoints, manual endpoints stay null, and overridden shorthand endpoints keep pointing back to the original candidate instead of drifting to the effective published endpoint id — GitHub issue #356; targeted REST runtime/hosting tests 4/4 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T92 typed published REST authoring-style runtime contract: Cephalon.Abstractions now exposes first-class RestEndpointRuntimeDescriptor.AuthoringStyle, Cephalon.AspNetCore now projects explicit module DSL, profile shorthand, generated shorthand, behavior-helper, and manual Minimal API values through /engine/rest-endpoints plus snapshot.RestEndpoints, Cephalon.Behaviors.Http now keeps candidate-projected endpoints aligned through the same runtime descriptor surface, and additive metadata.authoringStyle remains compatibility-only metadata instead of the canonical published-endpoint authorship answer — GitHub issue #357; targeted REST runtime/hosting tests 5/5 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T93 typed published REST route-boundary runtime contract: Cephalon.Abstractions now exposes first-class RestEndpointRuntimeDescriptor.RouteGroupPrefix plus RelativePattern, Cephalon.AspNetCore now projects the resolved published route-group boundary for behavior-backed and behavior-helper endpoints through /engine/rest-endpoints plus snapshot.RestEndpoints while manual Minimal API endpoints stay null, Cephalon.Behaviors.Http keeps candidate-projected endpoints aligned through the same typed route-boundary surface, and additive metadata.routeGroupPrefix plus metadata.relativePattern remain compatibility-only metadata instead of the canonical published-endpoint route-boundary answer — GitHub issue #358; targeted REST runtime/hosting tests 14/14 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T94 typed published REST behavior-type runtime contract: Cephalon.Abstractions now exposes first-class nullable RestEndpointRuntimeDescriptor.BehaviorType, Cephalon.AspNetCore now projects the concrete behavior implementation identity for behavior-backed and behavior-helper published endpoints through /engine/rest-endpoints plus snapshot.RestEndpoints while pure manual Minimal API endpoints stay null, Cephalon.Behaviors.Http keeps shorthand candidate ProjectedEndpoint entries aligned through the same runtime descriptor surface, and additive metadata.behaviorType remains compatibility-only metadata instead of the canonical published-endpoint behavior-implementation answer — GitHub issue #359; targeted REST runtime/hosting tests 3/3 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T95 typed published REST source-id runtime contract: Cephalon.Abstractions now exposes first-class nullable RestEndpointRuntimeDescriptor.SourceId, Cephalon.AspNetCore now projects the published source identity for behavior-backed, behavior-helper, and manual module-owned REST endpoints through /engine/rest-endpoints plus snapshot.RestEndpoints, Cephalon.Behaviors.Http keeps shorthand candidate ProjectedEndpoint entries aligned through the same runtime descriptor surface, and additive metadata.sourceId remains compatibility-only metadata instead of the canonical published-endpoint source-identity answer — GitHub issue #360; targeted REST runtime/hosting tests 3/3 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T96 typed route-boundary materialization cleanup: Cephalon.Behaviors.Http now resolves shorthand published route groups from first-class ProjectedEndpoint.RouteGroupPrefix during ASP.NET Core materialization so compatibility metadata.routeGroupPrefix no longer participates in internal route mapping, and targeted hosting coverage now proves materialization still succeeds when the typed property is present and compatibility metadata is absent while route-group override and split-group regressions stay green — GitHub issue #361; targeted hosting tests 6/6 (Sprint 36)
  • ENG-058-T97 shorthand REST endpoint-metadata override governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor with EndpointName, Summary, and Description, Cephalon.AspNetCore now binds and publishes those shorthand override actions through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, Cephalon.Behaviors.Http now projects the same effective endpoint metadata onto shorthand candidates and only marks metadata-only overrides as applied when they materially change the effective answer, and the ASP.NET Core runtime now keeps actual endpoint metadata plus /engine/rest-endpoints aligned with that same governed truth — GitHub issue #362; targeted REST projection/runtime hosting tests 9/9 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T98 shorthand REST capability-boundary override governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor with RequiredCapabilityKey and RestEndpointRuntimeDescriptor with first-class nullable RequiredCapabilityKey, Cephalon.AspNetCore now binds and publishes that shorthand override action through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, materializes the effective capability boundary from actual endpoint metadata for both shorthand and manual module-owned REST routes, and now treats the last RequireCapability(...) declaration as authoritative so a later host override can supersede an earlier shorthand configureEndpoint guard without double-enforcing both keys, while Cephalon.Behaviors.Http now projects the same governed capability boundary onto shorthand candidates and applies it during materialization so /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot stay aligned with the actual runtime trust boundary — GitHub issue #363; targeted hosting tests 192/192 plus package-surface tests 65/65 (Sprint 36)
  • ENG-058-T99 shorthand REST capability-boundary clear governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor with ClearRequiredCapability, Cephalon.AspNetCore now binds and publishes that shorthand override action through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, rejects any one override rule that tries to both set RequiredCapabilityKey and clear it, and materializes the clear through actual endpoint metadata and /engine/rest-endpoints so the effective runtime truth keeps RequiredCapabilityKey = null when the clear wins, while Cephalon.Behaviors.Http now projects that same clear onto shorthand candidates and applies it during materialization so /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot stay aligned when a host intentionally removes an inherited shorthand capability boundary — GitHub issue #364; targeted hosting tests 144/144 plus package-surface tests 65/65 (Sprint 36)
  • ENG-058-T100 published REST capability provenance: Cephalon.Abstractions now extends RestEndpointRuntimeDescriptor with nullable OriginalRequiredCapabilityKey plus AppliedOverrideId, Cephalon.Behaviors.Http now captures the source shorthand capability boundary during ASP.NET Core materialization before later host capability overrides run, and Cephalon.AspNetCore now projects that source-versus-effective capability lineage through /engine/rest-endpoints plus snapshot.RestEndpoints while leaving endpoint-level AppliedOverrideId null for capability-only no-op clear matches that do not change the published answer — GitHub issue #365; targeted hosting tests 146/146 plus package-surface tests 66/66 (Sprint 36)
  • ENG-058-T101 candidate no-op capability override truth: Cephalon.Behaviors.Http now registers shorthand runtime candidates after ASP.NET Core materialization and reconciles published candidate provenance against the actual mapped endpoint metadata, so /engine/rest-endpoint-candidates plus snapshot.RestEndpointCandidates now leave AppliedOverrideId = null when a capability-only override rule matches but does not change the effective published boundary, including no-op clears and same-key capability rewrites, while MatchedOverrideIds still shows that the host rule matched — GitHub issue #367; targeted REST projection/runtime hosting tests 147/147 (Sprint 36)
  • ENG-058-T102 published REST matched-override visibility: Cephalon.Abstractions now extends RestEndpointRuntimeDescriptor with ordered MatchedOverrideIds, Cephalon.Behaviors.Http now carries that same ordered shorthand override match set through behavior-backed endpoint materialization, and Cephalon.AspNetCore now projects it through /engine/rest-endpoints plus snapshot.RestEndpoints so the final published runtime answer keeps matched host override rules visible, including capability-only no-op matches that still leave AppliedOverrideId = null — GitHub issue #368; targeted REST projection/runtime hosting tests 147/147 plus package-surface tests 66/66 (Sprint 36)
  • ENG-058-T103 published REST original shorthand projection visibility: Cephalon.Abstractions now extends RestEndpointRuntimeDescriptor with nullable OriginalProjection, Cephalon.Behaviors.Http now carries that pre-override shorthand method/route/document-version/binding-plan truth through behavior-backed endpoint materialization, and Cephalon.AspNetCore now projects it through /engine/rest-endpoints plus snapshot.RestEndpoints so operators can compare original-versus-effective published endpoint shape without a candidate-catalog join while manual and behavior-helper endpoints stay null — GitHub issue #369; targeted REST runtime/hosting tests 60/60 plus package-surface tests 67/67 (Sprint 36)
  • ENG-058-T104 published REST original shorthand endpoint-metadata visibility: Cephalon.Abstractions now extends RestEndpointRuntimeDescriptor with nullable OriginalEndpointName, OriginalSummary, and OriginalDescription, Cephalon.Behaviors.Http now carries that pre-override shorthand endpoint-metadata truth through shorthand candidate resolution plus behavior-backed endpoint materialization, and Cephalon.AspNetCore now projects it through /engine/rest-endpoints plus snapshot.RestEndpoints while the candidate catalog keeps the same lineage visible on ProjectedEndpoint; manual and behavior-helper endpoints keep the original-metadata trio null — GitHub issue #370; targeted REST runtime/hosting tests 60/60 plus package-surface tests 68/68 (Sprint 36)
  • ENG-058-T105 shorthand REST endpoint-metadata clear governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor and Cephalon.AspNetCore override options with ClearEndpointName, ClearSummary, and ClearDescription, both public contracts now fail fast when one rule tries to both set and clear the same endpoint-metadata field, Cephalon.Behaviors.Http now projects shorthand metadata clears into the same effective candidate/runtime truth used for publication, and Cephalon.AspNetCore now removes the effective endpoint name/summary/description from actual ASP.NET Core metadata plus /engine/rest-endpoints while preserving original shorthand metadata lineage through OriginalEndpointName, OriginalSummary, and OriginalDescription — GitHub issue #371; targeted REST projection tests 93/93 plus targeted REST runtime/hosting tests 61/61 plus package-surface tests 68/68 (Sprint 36)
  • ENG-058-T106 published REST endpoint-metadata no-op override truth: Cephalon.Behaviors.Http now captures source shorthand endpoint metadata during ASP.NET Core materialization, reconciles metadata-only shorthand override provenance against the actual mapped endpoint metadata, and keeps /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot truthful when a matched metadata rewrite or clear rule does not change the published answer because the owning module already set or cleared the same metadata; those matches now keep MatchedOverrideIds visible while leaving AppliedOverrideId = null for the published candidate and endpoint runtime answers — GitHub issue #372; targeted REST projection tests 96/96 plus targeted REST runtime/hosting tests 63/63 plus package-surface tests 68/68 (Sprint 36)
  • ENG-058-T107 truthful shorthand REST tag override governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor plus RestEndpointCandidateProjectionDescriptor with TagName, Cephalon.AspNetCore now binds and publishes that shorthand override action through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides while carrying original shorthand tag lineage through RestEndpointRuntimeDescriptor.OriginalProjection, and Cephalon.Behaviors.Http now applies tag rewrites only when they materially change the effective published answer while splitting effective materialization groups by route-group prefix plus tag so actual ASP.NET Core endpoint tag metadata, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot stay aligned when only some candidates in one authored group are retagged — GitHub issue #373; targeted REST projection tests 100/100 plus targeted REST runtime/hosting tests 64/64 plus package-surface tests 70/70 (Sprint 36)
  • ENG-058-T108 truthful shorthand REST OpenAPI document-name governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor plus RestEndpointCandidateProjectionDescriptor with OpenApiDocumentName, Cephalon.AspNetCore now binds and publishes that shorthand override action through /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides, and Cephalon.Behaviors.Http now adds .WithOpenApiDocumentName(...), keeps same-value document rewrites truthful, re-derives the effective document name from ApiVersionMajor only when the authored shorthand group did not pin one explicitly, and splits effective materialization groups by route-group prefix plus document name plus tag so actual ASP.NET Core endpoint-group metadata, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot stay aligned when only some candidates in one authored group move documents — GitHub issue #374; targeted REST projection tests 106/106 plus targeted REST runtime/hosting tests 66/66 plus package-surface tests 72/72 (Sprint 36)
  • ENG-058-T109 shorthand REST document-and-tag selector targeting: Cephalon.Abstractions now extends RestEndpointSuppressionDescriptor plus RestEndpointOverrideDescriptor with OpenApiDocumentNames and TagNames, Cephalon.AspNetCore now binds and publishes those selector arrays through /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and snapshot, and Cephalon.Behaviors.Http now matches those selectors against the original shorthand document/tag identity before override actions are applied so hosts can target one of several same-behavior candidates without depending on rewritten route shape — GitHub issue #375; targeted REST projection tests 108/108 plus targeted REST runtime/hosting tests 68/68 plus package-surface tests 73/73 (Sprint 36)
  • ENG-058-T110 shorthand REST clear-bindings governance: Cephalon.Abstractions now extends RestEndpointOverrideDescriptor and Cephalon.AspNetCore override options with ClearBindings, ASP.NET Core config binding plus /engine/rest-endpoint-overrides and snapshot.RestEndpointOverrides now publish that shorthand-only reset action, and Cephalon.Behaviors.Http now lets a host discard a shorthand candidate’s explicit binding plan so request composition returns to the implicit route/query/body baseline while failing fast if the effective route would only remain satisfiable through removed explicit route-binding aliases — GitHub issue #376; targeted REST projection tests 114/114 plus targeted REST runtime/hosting tests 70/70 plus package-surface tests 74/74 (Sprint 36)
  • ENG-058-T111 truthful shorthand REST binding-order no-op governance: Cephalon.Behaviors.Http now treats reorder-only override rewrites of an equivalent explicit binding set as no-op governance, keeps source explicit binding order authoritative on the projected candidate and published endpoint, and leaves AppliedOverrideId = null while preserving MatchedOverrideIds when the effective binding semantics do not change — GitHub issue #377; targeted REST projection tests 115/115 plus targeted REST runtime/hosting tests 71/71 (Sprint 36)
  • ENG-058-T112 shared shorthand REST binding-equivalence truth across projection and materialization: Cephalon.Behaviors.Http now centralizes equivalent explicit binding-set comparison in one shared comparer used by candidate resolution, RestBehaviorEndpointProjection.WithBindings(...), and ASP.NET Core structural override reconciliation, so reorder-only equivalent binding sets stay semantic no-op governance even for synthetic or future candidate paths and published endpoints no longer stamp endpoint-level override provenance when only descriptor order changes — GitHub issue #378; targeted REST projection tests 117/117 plus targeted REST runtime/hosting tests 71/71 (Sprint 36)
  • ENG-058-T113 truthful shorthand REST governance diagnostics visibility: Cephalon.Behaviors.Http now publishes a stable Cephalon.Behaviors.Http diagnostics convention through /engine/diagnostics with initial event ids 5200 through 5204 for governance suppression, precedence suppression, applied overrides, no-op override matches, and preserved binding fallback, and startup mapping now emits those information-level events only when logging is enabled while reconciling published candidate answers against post-materialization runtime truth whenever the runtime candidate registry is active so no-op published endpoints do not falsely claim applied-override provenance; ENG-058-T124 later extended that convention with authoring-policy suppression event 5205, and ENG-058-T131 later extended it again with governance-skipped explicit-DSL event 5206 — GitHub issue #379; targeted REST projection tests 117/117 plus targeted REST runtime/hosting tests 73/73 (Sprint 36)
  • ENG-058-T114 truthful shorthand REST remaining-body fallback visibility: Cephalon.Abstractions now extends RestEndpointBindingFallbackMode with PreserveRemainingBodyFallback, Cephalon.Behaviors.Http now resolves that typed fallback mode for body-capable behavior-backed REST endpoints whenever explicit bindings still leave deterministic remaining request-body surface, and Cephalon.AspNetCore now carries the same answer through actual endpoint metadata plus /engine/rest-endpoints and snapshot.RestEndpoints while keeping metadata.bindingFallbackMode = preserve-remaining-body-fallback as compatibility-only metadata — GitHub issue #380; targeted REST projection tests 118/118 plus targeted REST runtime/hosting tests 73/73 plus package-surface tests 75/75 (Sprint 36)
  • ENG-058-T115 truthful shorthand REST preserved-fallback diagnostics parity: Cephalon.Behaviors.Http now emits RestEndpointBindingFallbackPreserved event 5204 for any changed non-null typed BindingFallbackMode instead of only the earlier implicit-query preservation case, so startup logging stays aligned when merge removal or other shorthand override reconciliation preserves PreserveRemainingBodyFallback; focused projection and hosting coverage now prove both the runtime-catalog answer and emitted logging for that body-fallback path — GitHub issue #381; targeted REST projection tests 119/119 plus targeted REST runtime/hosting tests 74/74 (Sprint 36)
  • ENG-058-T116 centralize shorthand REST binding-fallback wire names: Cephalon.Abstractions now exposes RestEndpointBindingFallbackModeExtensions.GetWireName() plus TryParseWireName(...) as the canonical compatibility bridge for RestEndpointBindingFallbackMode, Cephalon.AspNetCore now derives additive metadata.bindingFallbackMode values from that helper instead of maintaining independent hardcoded strings, and the public XML/docs wording now describes both preserved implicit-query and remaining request-body fallback semantics truthfully — GitHub issue #382; targeted REST projection tests 119/119 plus targeted REST runtime/hosting tests 74/74 plus package-surface tests 77/77 (Sprint 36)
  • ENG-058-T117 compile-time shorthand REST route-pattern validation: Cephalon.Behaviors.SourceGen now rejects malformed BehaviorRestProfileAttribute.RelativePattern placeholder syntax through ABT0026, withholds generated GetRestProfiles() hints when the declared route pattern is malformed, and BehaviorRestProfileResolver now parses declared route patterns during runtime normalization even when no explicit bindings are present so direct attribute fallback or stale generated hints still fail fast before shorthand publication can materialize an invalid route shape — GitHub issue #383; targeted source-generator tests 27/27 plus targeted REST runtime/hosting tests 120/120 (Sprint 36)
  • ENG-058-T118 shorthand REST binding-fallback selector targeting: Cephalon.Abstractions now extends RestEndpointSuppressionDescriptor plus RestEndpointOverrideDescriptor with BindingFallbackModes, Cephalon.AspNetCore now binds and publishes those selector arrays through /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and snapshot, and Cephalon.Behaviors.Http now matches those selectors against the original shorthand BindingFallbackMode identity before override actions are applied so hosts can target one of several same-behavior candidates by preserved fallback semantics without depending on rewritten published shape — GitHub issue #384; targeted REST projection tests 120/120 plus targeted REST runtime/hosting tests 76/76 plus package-surface tests 78/78 (Sprint 36)
  • ENG-058-T119 profile-authored shorthand REST implicit query-fallback parity: Cephalon.Behaviors.Http now extends BehaviorRestProfileAttribute plus BehaviorRestProfileDescriptor with PreserveImplicitQueryFallback so explicit metadata-only REST profiles can keep the remaining implicit query-string fallback surface intentionally, Cephalon.Behaviors.SourceGen now validates that authoring contract through ABT0027 and carries the flag through generated GetRestProfiles() output, and BehaviorRestProfileResolver now re-checks the same rule during runtime fallback so shorthand projection/runtime surfaces keep PreserveSourceImplicitFallback aligned for module-owned profile consumption — GitHub issue #385; targeted source-generator tests 29/29 plus targeted REST projection/runtime hosting tests 203/203 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T120 shorthand REST original binding-plan selector targeting: Cephalon.Abstractions now extends RestEndpointSuppressionDescriptor plus RestEndpointOverrideDescriptor, and Cephalon.AspNetCore suppression/override options, with exact original explicit TargetBindings selector sets that the runtime catalogs publish through /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and snapshot; Cephalon.Behaviors.Http now matches those selectors against the original shorthand explicit binding-plan identity before override actions are applied, using descriptor-set equivalence so hosts can target route-only versus richer explicitly bound candidates without depending on rewritten published shape — GitHub issue #386; targeted REST projection/runtime hosting tests 6/6 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T121 shorthand REST publication-group authoring-style visibility: Cephalon.Abstractions now exposes RestEndpointPublicationGroupAuthoringStyleDescriptor, and RestEndpointPublicationGroupDescriptor.AuthoringStyleSummaries now derives a first-class per-authoring-style summary directly from the grouped candidate truth so /engine/rest-endpoint-publication-groups plus snapshot.RestEndpointPublicationGroups also show which authoring styles participated, which remained published, and which were precedence-suppressed or governance-suppressed without changing publication semantics — GitHub issue #387; targeted REST runtime/hosting tests 3/3 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T122 REST publication-group authoring-policy contract: Cephalon.Abstractions now also exposes RestEndpointPublicationGroupAuthoringPolicyDescriptor, grouped publication answers now also carry RestEndpointPublicationGroupDescriptor.AuthoringPolicy, RestApi:AuthoringPolicies:{behaviorId} now binds default-versus-configured authoring-policy intent for AllowMultiplePublishedCandidates plus preferred/allowed/disallowed authoring styles, and /engine/rest-endpoint-publication-groups plus snapshot.RestEndpointPublicationGroups now round-trip that effective policy without changing current publication semantics — GitHub issue #388; targeted REST runtime/hosting tests 4/4 plus package-surface tests 4/4 (Sprint 36)
  • ENG-058-T123 shorthand REST allow-multiple authoring-policy enforcement: Cephalon.Behaviors.Http now honors RestApi:AuthoringPolicies:{behaviorId}:AllowMultiplePublishedCandidates during candidate resolution so lower-precedence unsuppressed shorthand candidates can remain published together when one grouped behavior boundary explicitly opts into that outcome, while route-collision validation remains authoritative and co-published shorthand candidates now disambiguate effective endpoint names deterministically by authoring style, route shape, and candidate identity while preserving OriginalEndpointName lineage; the broader preferred/allowed/disallowed authoring-style enforcement then landed in ENG-058-T124 — GitHub issue #389; targeted REST projection tests 1/1 plus targeted REST runtime/hosting tests 3/3 (Sprint 36)
  • ENG-058-T124 shorthand REST authoring-policy suppression truth: Cephalon.Abstractions now exposes RestEndpointAuthoringPolicySuppressionKind plus RestEndpointCandidateRuntimeDescriptor.SuppressedByAuthoringPolicyKind, grouped publication answers now also expose authoring-policy-suppressed candidate buckets, and Cephalon.Behaviors.Http now enforces PreferredAuthoringStyle, AllowedAuthoringStyles, and DisallowedAuthoringStyles for shorthand behavior-module-profile and behavior-module-generated candidates while keeping explicit module DSL publication authoritative; startup diagnostics/logging now also emit event 5205 for authoring-policy suppression so runtime truth distinguishes governance suppression, authoring-policy suppression, and candidate-precedence publication cleanly — GitHub issue #390; targeted REST projection tests 4/4 plus targeted REST runtime/hosting tests 4/4 plus package-surface tests 6/6 (Sprint 36)
  • ENG-058-T125 truthful shorthand REST selected-override visibility: Cephalon.Abstractions now exposes nullable SelectedOverrideId on both RestEndpointCandidateRuntimeDescriptor and RestEndpointRuntimeDescriptor, Cephalon.Behaviors.Http now keeps the winning shorthand override rule visible on published candidates and endpoints even when post-materialization reconciliation proves the rule was a runtime no-op and AppliedOverrideId must remain null, and governance no-op diagnostics/logging now explicitly name the selected winning override instead of only echoing the matched set — GitHub issue #391; targeted REST projection/runtime hosting tests 10/10 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T126 truthful shorthand REST governance selection-basis visibility: Cephalon.Abstractions now exposes RestEndpointGovernanceRuleSelectionBasis plus candidate SuppressionSelectionBasis and OverrideSelectionBasis, RestEndpointRuntimeDescriptor now also exposes endpoint-level OverrideSelectionBasis, and Cephalon.Behaviors.Http plus Cephalon.AspNetCore now carry the earliest decisive specificity answer through shorthand candidate resolution, post-materialization publication, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot so operators can see not only which rule won but why it beat the runner-up — GitHub issue #392; targeted REST projection/runtime hosting tests 6/6 plus package-surface tests 10/10 (Sprint 36)
  • ENG-058-T127 derive inline generated REST shorthand from module descriptor id: Cephalon.Behaviors.Http now exposes RestBehaviorEngineBuilderExtensions.AddGeneratedRestBehaviorModule<TMarker>(EngineBuilder, ModuleDescriptor, Action<IRestBehaviorEndpointGroupBuilder>?), which derives the generated behavior-id prefix from ModuleDescriptor.Id for the common inline module case, reuses the same fail-fast deterministic route-group validation already enforced by GroupFromBehaviorIdPrefix(...), preserves the explicit overload when the module id and generated prefix should differ, and still never publishes public REST from [AppBehavior] alone — GitHub issue #393; targeted REST runtime/hosting tests 4/4 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T128 explicit module-DSL host-governance opt-in: Cephalon.Behaviors.Http now exposes IRestBehaviorEndpointGroupBuilder.AllowHostGovernance(), which lets an explicit module-owned route group opt into ASP.NET Core RestApi:Suppressions and RestApi:Overrides without changing its authoring style; Cephalon.Abstractions now keeps that runtime truth visible through RestEndpointCandidateProjectionDescriptor.AllowsHostGovernance plus published OriginalProjection, shorthand candidates still participate by default, and host rules still leave explicit module DSL out of scope unless they explicitly target authoring style behavior-module-dsl — GitHub issue #394; targeted REST runtime/hosting tests 5/5 plus package-surface tests 98/98 (Sprint 36)
  • ENG-058-T129 explicit REST governance-skipped visibility: Cephalon.Abstractions now exposes ordered SkippedSuppressionIds and SkippedOverrideIds on both RestEndpointCandidateRuntimeDescriptor and RestEndpointRuntimeDescriptor, and Cephalon.Behaviors.Http plus Cephalon.AspNetCore now keep those skipped rule ids visible when host suppression or override rules target an explicit module-DSL candidate that did not opt into host governance; Matched*, suppression, precedence, and authoring-policy truth remain unchanged, so runtime operators can distinguish governance-ineligible explicit ownership from a selector miss — GitHub issue #395; targeted REST projection/runtime hosting tests 5/5 plus package-surface tests 98/98 (Sprint 36)
  • ENG-058-T130 grouped REST host-governance eligibility and skipped-rule visibility: Cephalon.Abstractions now exposes grouped HostGovernanceEligibleCandidateIds, HostGovernanceIneligibleCandidateIds, SkippedSuppressionIds, and SkippedOverrideIds on both RestEndpointPublicationGroupDescriptor and RestEndpointPublicationGroupAuthoringStyleDescriptor, and the ASP.NET Core publication-group runtime catalog now derives those summaries directly from candidate truth so /engine/rest-endpoint-publication-groups plus snapshot.RestEndpointPublicationGroups keep explicit module-DSL governance ineligibility visible without candidate-by-candidate reconstruction — GitHub issue #396; targeted REST publication-group hosting tests 2/2 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T131 skipped explicit REST governance diagnostics: Cephalon.Behaviors.Http now extends the stable Cephalon.Behaviors.Http diagnostics convention with RestEndpointGovernanceSkipped event 5206, and startup materialization now emits that information-level log when host suppression or override rules target an explicit module-DSL candidate that did not opt into host governance, so /engine/diagnostics plus startup logging distinguish governance-ineligible explicit ownership from selector misses and actual winning host rules while echoing the skipped suppression and override ids — GitHub issue #397; targeted REST runtime/hosting tests 5/5 (Sprint 36)
  • ENG-058-T132 configured and effective REST override action visibility: Cephalon.Abstractions now exposes typed RestEndpointOverrideActionKind, configured RestEndpointOverrideDescriptor.ActionKinds, and selected-versus-applied override action kinds on both RestEndpointCandidateRuntimeDescriptor and RestEndpointRuntimeDescriptor, while Cephalon.AspNetCore plus Cephalon.Behaviors.Http now propagate those declared-versus-effective action dimensions through /engine/rest-endpoint-overrides, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot so no-op override winners keep their selected dimensions visible without falsely claiming a material runtime rewrite — GitHub issue #398; targeted REST runtime/hosting tests 2/2 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T133 REST override action visibility in governance diagnostics: Cephalon.Behaviors.Http now extends the stable override-applied and override-no-op diagnostics story so startup logging and /engine/diagnostics both expose selected-versus-applied override action-kind wire names beside the winning override ids, keeping the operator log surface aligned with the runtime-catalog truth from ENG-058-T132 without forcing manual route diffs — GitHub issue #399; targeted REST runtime/hosting tests 2/2 (Sprint 36)
  • ENG-058-T134 REST governance selection-basis visibility in startup diagnostics: Cephalon.Behaviors.Http now extends the stable governance diagnostics story so startup logging and /engine/diagnostics expose the decisive suppression selection-basis wire name on event 5200 plus the decisive override selection-basis wire name on events 5202 and 5203, keeping operator-facing startup truth aligned with the runtime-catalog SuppressionSelectionBasis / OverrideSelectionBasis answers from ENG-058-T126 — GitHub issue #401; targeted REST runtime/hosting tests 2/2 (Sprint 36)
  • ENG-058-T135 REST binding-fallback wire-name parity in startup diagnostics: Cephalon.Behaviors.Http now logs RestEndpointBindingFallbackPreserved event 5204 with the stable RestEndpointBindingFallbackMode wire name from RestEndpointBindingFallbackModeExtensions.GetWireName() instead of the raw enum member name, keeping startup operator truth aligned with JSON serialization, additive compatibility metadata, and the runtime-catalog BindingFallbackMode contract — GitHub issue #402; targeted REST runtime/hosting tests 2/2 (Sprint 36)
  • ENG-058-T136 strict REST binding-fallback selector wire-name parsing: Cephalon.AspNetCore now treats RestApi:Suppressions:*:BindingFallbackModes and RestApi:Overrides:*:BindingFallbackModes as wire-name-only config surfaces, rejecting legacy PascalCase enum-member aliases so host governance, runtime catalogs, diagnostics, and compatibility metadata all share the same stable fallback-mode vocabulary end-to-end — GitHub issue #403; targeted REST runtime/hosting tests 2/2 (Sprint 36)
  • ENG-058-T137 REST override binding-mode wire-name parity: Cephalon.Abstractions now exposes RestEndpointOverrideBindingModeExtensions plus stable replace-explicit / merge-explicit JSON wire names for RestEndpointOverrideBindingMode, and Cephalon.AspNetCore now treats RestApi:Overrides:*:BindingMode as the same wire-name-only config surface so host governance config, runtime catalogs, and serialized override truth all use one canonical vocabulary while rejecting legacy PascalCase enum-member aliases — GitHub issue #404; targeted REST runtime/hosting tests 2/2 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T138 REST override binding-mode unspecified wire-name parity: Cephalon.Abstractions now gives RestEndpointOverrideBindingMode.Unspecified the stable JSON/runtime wire name unspecified, and /engine/rest-endpoint-overrides plus snapshot.RestEndpointOverrides now preserve that canonical wire name for ClearBindings rules that omitted an explicit binding mode while other rules still normalize to replace-explicit or merge-explicit; Cephalon.AspNetCore still keeps RestApi:Overrides:*:BindingMode explicit-mode-only for host config (replace-explicit / merge-explicit) — GitHub issue #405; targeted REST runtime/hosting tests 1/1 plus package-surface tests 4/4 (Sprint 36)
  • ENG-058-T139 REST binding-source wire-name parity: Cephalon.Abstractions now exposes RestEndpointBindingSourceExtensions plus stable route / query / header / body JSON wire names for RestEndpointBindingSource, Cephalon.AspNetCore now treats RestApi:Overrides:*:Bindings:*:Source, RestApi:Overrides:*:TargetBindings:*:Source, and RestApi:Suppressions:*:TargetBindings:*:Source as the same wire-name-only config surface, runtime binding-descriptor JSON now uses that canonical vocabulary across /engine/rest-endpoints, /engine/rest-endpoint-overrides, /engine/rest-endpoint-suppressions, and snapshot, and the hand-authored docs now correct the T138 wording so bindingMode = unspecified is described as a ClearBindings-only preserved omission case — GitHub issue #406; targeted REST runtime/hosting tests 7/7 plus package-surface tests 6/6 (Sprint 36)
  • ENG-058-T140 stabilize REST candidate-status wire names: Cephalon.Abstractions now exposes RestEndpointCandidateStatusExtensions plus stable published / suppressed JSON wire names for RestEndpointCandidateStatus, and /engine/rest-endpoint-candidates, /engine/rest-endpoint-candidates/{candidateId}, and snapshot.RestEndpointCandidates now expose candidate publication state through that canonical operator-facing vocabulary instead of raw enum-number serialization — GitHub issue #407; targeted REST runtime/hosting tests 1/1 plus package-surface tests 4/4 (Sprint 36)
  • ENG-058-T141 normalize behavior REST binding-source wire names: Cephalon.Behaviors.Http now exposes BehaviorRestBindingSourceExtensions plus stable route / query / header / body JSON wire names for BehaviorRestBindingSource, and Cephalon.Behaviors.SourceGen now validates [BehaviorRestBinding] metadata against that canonical wire-name vocabulary while still emitting the resolved enum member names into generated GetRestProfiles() hints so future enum-member renames that preserve the wire-name contract do not break module-owned REST shorthand — GitHub issue #408; targeted source-generator tests 3/3 plus package-surface tests 6/6 (Sprint 36)
  • ENG-058-T142 normalize behavior REST method wire names: Cephalon.Behaviors.Http now exposes BehaviorRestMethodExtensions plus stable get / post / put / patch / delete JSON wire names for BehaviorRestMethod, and Cephalon.Behaviors.SourceGen now validates [BehaviorRestProfile] metadata against that canonical wire-name vocabulary while still emitting the resolved enum member names into generated GetRestProfiles() hints so future enum-member renames that preserve the wire-name contract do not break module-owned REST shorthand — GitHub issue #409; targeted source-generator tests 4/4 plus package-surface tests 7/7 (Sprint 36)
  • ENG-058-T143 align behavior REST runtime guidance with stable wire names: Cephalon.Behaviors.Http now reuses the same canonical get / post / put / patch / delete and route / query / header / body vocabularies in runtime attribute-fallback and explicit binding-plan normalization errors, so MapProfile<TBehavior>() fallback, binding-plan normalization, and last-mile profile-method conversion keep operator guidance aligned with JSON serialization and source generation — GitHub issue #410; targeted hosting/runtime tests 3/3 (Sprint 36)
  • ENG-058-T144 finish behavior REST method-guidance parity: Cephalon.Behaviors.Http now also reuses the canonical get / post / put / patch / delete vocabulary in non-body method body-binding rejections and unsupported REST method parser failures, so source generation, JSON serialization, runtime fallback, body-capability validation, and parser guidance all point at one stable behavior-authored REST method contract — GitHub issue #411; targeted hosting/runtime tests 3/3 (Sprint 36)
  • ENG-058-T145 lock authoring-policy suppression wire names in runtime JSON: /engine/rest-endpoint-candidates, /engine/rest-endpoint-candidates/{candidateId}, and snapshot.RestEndpointCandidates now have targeted hosting/runtime coverage that locks SuppressedByAuthoringPolicyKind onto the canonical disallowed-authoring-style, not-allowed-authoring-style, and preferred-authoring-style-selected wire names, so operator-facing shorthand-governance payloads do not drift back to raw enum-member or numeric serialization behavior — GitHub issue #412; targeted hosting/runtime tests 1/1 (Sprint 36)
  • ENG-058-T146 surface authoring-policy suppression kinds in publication groups: Cephalon.Abstractions now exposes RestEndpointPublicationGroupAuthoringPolicySuppressionDescriptor, grouped publication answers now also publish AuthoringPolicySuppressionSummaries at both the behavior-group level and inside each RestEndpointPublicationGroupAuthoringStyleDescriptor, and /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, plus snapshot.RestEndpointPublicationGroups now keep the canonical grouped disallowed-authoring-style and not-allowed-authoring-style suppression breakdown visible without re-reading the candidate catalog — GitHub issue #413; targeted hosting/runtime tests 2/2 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T147 surface grouped governance rule summaries in publication groups: Cephalon.Abstractions now exposes RestEndpointPublicationGroupGovernanceSuppressionSummaryDescriptor plus RestEndpointPublicationGroupGovernanceOverrideSummaryDescriptor, grouped publication answers now also publish GovernanceSuppressionSummaries and GovernanceOverrideSummaries at both the behavior-group level and inside each RestEndpointPublicationGroupAuthoringStyleDescriptor, and /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, plus snapshot.RestEndpointPublicationGroups now keep matched-versus-suppressed and matched/selected/applied host-rule outcomes visible, including no-op override winners whose applied bucket stays empty, without re-reading the candidate catalog — GitHub issue #414; targeted hosting/runtime tests 3/3 plus package-surface tests 4/4 (Sprint 36)
  • ENG-058-T148 surface grouped skipped-governance rule summaries in publication groups: Cephalon.Abstractions now exposes RestEndpointPublicationGroupGovernanceSkippedSuppressionSummaryDescriptor plus RestEndpointPublicationGroupGovernanceSkippedOverrideSummaryDescriptor, grouped publication answers now also publish SkippedSuppressionSummaries and SkippedOverrideSummaries at both the behavior-group level and inside each RestEndpointPublicationGroupAuthoringStyleDescriptor, and /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, plus snapshot.RestEndpointPublicationGroups now keep per-rule candidate mappings for governance-ineligible explicit module-DSL routes visible without re-reading the candidate catalog — GitHub issue #415; targeted hosting/runtime tests 4/4 plus package-surface tests 8/8 (Sprint 36)
  • ENG-058-T149 surface grouped governance provenance in publication groups: Cephalon.Abstractions now exposes RestEndpointPublicationGroupGovernanceSelectionBasisSummaryDescriptor plus RestEndpointPublicationGroupGovernanceOverrideActionKindSummaryDescriptor, grouped suppression summaries now also publish SelectionBasisSummaries, grouped override summaries now also publish SelectionBasisSummaries plus SelectedActionKindSummaries / AppliedActionKindSummaries, and /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, plus snapshot.RestEndpointPublicationGroups now keep grouped decisive governance-precedence and declared-versus-effective override-action visibility aligned with candidate runtime truth without re-reading the candidate catalog — GitHub issue #416; targeted hosting/runtime tests 4/4 plus package-surface tests 10/10 (Sprint 36)
  • ENG-058-T150 surface rule-centric REST governance effects: Cephalon.Abstractions now extends RestEndpointSuppressionDescriptor with MatchedCandidateIds, SuppressedCandidateIds, SkippedCandidateIds, and SelectionBases, and extends RestEndpointOverrideDescriptor with MatchedCandidateIds, SelectedCandidateIds, AppliedCandidateIds, SkippedCandidateIds, SelectionBases, SelectedActionKinds, and AppliedActionKinds; Cephalon.AspNetCore now derives those per-rule runtime-effect buckets lazily from the candidate runtime catalog so /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and the matching snapshot surfaces answer both configured rule intent and actual runtime footprint without manually rejoining candidate payloads — GitHub issue #417; targeted hosting/runtime tests 4/4 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T151 surface rule-centric REST governance provenance summaries: Cephalon.Abstractions now exposes reusable RestEndpointGovernanceSelectionBasisSummaryDescriptor and RestEndpointGovernanceOverrideActionKindSummaryDescriptor contracts, extends RestEndpointSuppressionDescriptor with grouped SelectionBasisSummaries, and extends RestEndpointOverrideDescriptor with grouped SelectionBasisSummaries, SelectedActionKindSummaries, and AppliedActionKindSummaries; Cephalon.AspNetCore now derives those grouped per-rule provenance buckets from the same candidate runtime catalog so /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and the matching snapshot surfaces can answer which candidate ids belonged to each decisive basis or override-action bucket without reopening grouped publication answers — GitHub issue #418; targeted hosting/runtime tests 3/3 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T152 surface rule-centric REST authoring-policy runtime catalog: Cephalon.Abstractions now exposes IRestEndpointAuthoringPolicyRuntimeCatalog, RestEndpointAuthoringPolicyDescriptor, and RestEndpointAuthoringPolicySuppressionSummaryDescriptor; Cephalon.AspNetCore now derives one behavior-level authoring-policy runtime answer from configured RestApi:AuthoringPolicies plus candidate truth, publishes /engine/rest-endpoint-authoring-policies, /engine/rest-endpoint-authoring-policies/{behaviorId}, and the matching snapshot surface, keeps explicitly configured-but-unmatched policies visible, and separates retained/published/precedence/governance buckets plus grouped authoring-policy suppression summaries without reopening grouped publication answers — GitHub issue #419; targeted hosting/runtime tests 3/3 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T153 surface rule-centric REST authoring-policy style summaries: Cephalon.Abstractions now also exposes RestEndpointAuthoringPolicyAuthoringStyleDescriptor, RestEndpointAuthoringPolicyDescriptor now also carries AuthoringStyleSummaries, and Cephalon.AspNetCore now derives per-authoring-style candidate, retained, published, precedence-suppressed, governance-suppressed, and authoring-policy-suppressed buckets plus grouped suppression summaries for /engine/rest-endpoint-authoring-policies, /engine/rest-endpoint-authoring-policies/{behaviorId}, and snapshot.RestEndpointAuthoringPolicies, while explicitly configured-but-unmatched policies keep an empty style-summary set — GitHub issue #420; targeted hosting/runtime tests 3/3 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T154 surface rule-centric REST authoring-policy governance eligibility and skipped-rule visibility: RestEndpointAuthoringPolicyDescriptor and RestEndpointAuthoringPolicyAuthoringStyleDescriptor now also keep HostGovernanceEligibleCandidateIds, HostGovernanceIneligibleCandidateIds, SkippedSuppressionIds, and SkippedOverrideIds, and Cephalon.AspNetCore now derives those behavior-level and per-style governance-eligibility buckets directly from candidate runtime truth so /engine/rest-endpoint-authoring-policies, /engine/rest-endpoint-authoring-policies/{behaviorId}, and snapshot.RestEndpointAuthoringPolicies keep explicit ownership and skipped host-rule visibility readable without reopening grouped publication answers — GitHub issue #421; targeted hosting/runtime tests 4/4 plus package-surface tests 3/3 (Sprint 36)
  • ENG-058-T155 surface rule-centric REST authoring-policy governance summaries: Cephalon.Abstractions now exposes reusable RestEndpointGovernanceSuppressionSummaryDescriptor, RestEndpointGovernanceOverrideSummaryDescriptor, RestEndpointGovernanceSkippedSuppressionSummaryDescriptor, and RestEndpointGovernanceSkippedOverrideSummaryDescriptor; RestEndpointAuthoringPolicyDescriptor plus RestEndpointAuthoringPolicyAuthoringStyleDescriptor now also carry grouped governance suppression, override, and skipped-rule summaries; and Cephalon.AspNetCore now derives those rule summaries directly from candidate runtime truth so /engine/rest-endpoint-authoring-policies, /engine/rest-endpoint-authoring-policies/{behaviorId}, and snapshot.RestEndpointAuthoringPolicies can answer matched-versus-suppressed, selected-versus-applied, and skipped-rule candidate mappings without reopening grouped publication answers — GitHub issue #422; targeted hosting/runtime tests 5/5 plus package-surface tests 6/6 (Sprint 36)
  • ENG-058-T156 shorthand REST original endpoint-name selector targeting: Cephalon.Abstractions now extends RestEndpointSuppressionDescriptor plus RestEndpointOverrideDescriptor, and Cephalon.AspNetCore suppression/override options, with EndpointNames; Cephalon.Behaviors.Http now matches those selectors against ProjectedEndpoint.OriginalEndpointName before override actions are applied so hosts can target one of several same-behavior shorthand candidates by authored endpoint metadata without depending on rewritten published shape, selector specificity now counts EndpointNames consistently, the suppression/override runtime catalogs publish those selector arrays directly, and Cephalon.AspNetCore now rebuilds authoring-policy governance summaries through host-local builders instead of abstraction-internal helpers so the assembly boundary stays clean — issue #423; targeted hosting/runtime tests 3/3 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T157 shorthand REST inline-helper convenience overloads: Cephalon.Behaviors.Http now adds moduleId / displayName / description convenience overloads for AddRestBehaviorModule<TMarker>(), AddGeneratedRestBehaviorModule<TMarker>(configureGroup?), and AddGeneratedRestBehaviorModule<TMarker>(behaviorIdPrefix, configureGroup?) so hosts can keep the inline module-owned REST path terse without manually constructing ModuleDescriptor; the new overloads delegate to the existing descriptor-based helpers, preserve the same marker-based source-assembly plus module-identity semantics, keep the normalized projection/materialization/candidate/governance pipeline unchanged, and retain the explicit generated behaviorIdPrefix escape hatch when inline module identity and generated ownership should differ — issue #424; targeted hosting/runtime tests 6/6 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T158 shorthand REST governance-scope selector targeting: Cephalon.Behaviors.Http now adds IRestBehaviorEndpointGroupBuilder.WithHostGovernanceScope(...), route groups now preserve that authored scope through RestEndpointCandidateProjectionDescriptor.HostGovernanceScope, Cephalon.Abstractions plus Cephalon.AspNetCore suppression/override contracts now expose HostGovernanceScopes, selector matching plus specificity now count that dimension consistently, and explicit module-DSL routes can carry a governance scope without entering host governance unless AllowHostGovernance() still opts them in separately — issue #425; targeted hosting/runtime tests 8/8 plus package-surface tests 5/5 (Sprint 36)
  • ENG-058-T159 scope-first shorthand REST governance targeting: RestEndpointSuppressionOptions and RestEndpointOverrideOptions now treat HostGovernanceScopes as a primary selector beside CandidateIds, Behaviors, and Modules, so scope-only host-governance rules no longer fail fast while empty-selector rules still do; targeted runtime coverage now proves that scope-only rules work for shorthand candidates and governable explicit module-DSL routes without hiding original-versus-effective runtime truth — issue #426; targeted projection tests 4/4 plus targeted hosting/runtime tests 6/6 (Sprint 36)
  • ENG-058-T160 scope-first REST runtime parity and action-family provenance: scope-only HostGovernanceScopes targeting is now explicitly proven through the suppression, override, publication-group, authoring-policy, and snapshot answers without falling back to behavior-id selectors, and ASP.NET Core materialization now only emits applied override provenance when the selected rule’s own capability or endpoint-metadata action family materially changed the published answer so capability-only no-op matches remain selected-only — issue #427; filtered hosting/runtime suites 245/245 plus package-surface tests 146/146 (Sprint 36)
  • ENG-058-T161 explicit preserved query-fallback placeholder promotion: Cephalon.Behaviors.Http now lets shorthand profiles that already declare explicit bindings and intentionally preserve source implicit query fallback promote that remaining query surface into added route placeholders through host overrides, keeps PreserveImplicitQueryFallback aligned through override normalization whenever the effective binding plan still has explicit bindings and should retain that source contract, and now clears candidate/published BindingFallbackMode truthfully once the effective binding plan fully consumes the preserved fallback surface — issue #480; targeted projection tests 4/4 plus targeted hosting/runtime tests 4/4 (Sprint 36)
  • ENG-058-T162 merge-mode explicit-query binding-withdrawal safety and preserved runtime truth: Cephalon.Behaviors.Http now rejects merge-explicit shorthand overrides that would stop explicitly binding a source query-bound property on non-body methods unless the source profile explicitly preserved implicit query fallback or the host clears bindings entirely, and candidate plus published runtime truth now keep OriginalProjection.BindingFallbackMode as authored-source truth while ProjectedEndpoint.BindingFallbackMode can surface newly re-exposed PreserveSourceImplicitFallback after the override — issue #481; targeted projection tests 2/2 plus targeted hosting/runtime tests 2/2 (Sprint 36)
  • ENG-058-T163 low-code generated REST profile-group shorthand with preserved module ownership: Cephalon.Behaviors.Http now exposes IRestBehaviorModuleBuilder.MapGeneratedProfileGroups(string) plus the shared-group-configuration overload so an owning module can fan one generated behavior-id root prefix out into several derived route groups without restating each group manually; Cephalon groups matching generated profiles by their parent behavior-id prefix, reuses GroupFromBehaviorIdPrefix(...) derivation plus the same owning-module sourcegen-first profile resolution path, applies shared group-level conventions before publication, and keeps generated publication on the existing behavior-module-generated candidate, publication-group, governance, and runtime-catalog path instead of inventing a new publication source — issue #482; targeted projection tests 1/1 plus targeted hosting/runtime tests 1/1 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T164 behavior-id-prefix REST governance selectors with preserved runtime truth: Cephalon.Abstractions now extends the REST suppression/override contracts and Cephalon.AspNetCore config binding with BehaviorIdPrefixes, those prefixes now count as primary selectors beside exact candidate/behavior/module/scope selectors, Cephalon.Behaviors.Http now matches them against the original dot-separated behavior-id hierarchy before override actions are applied so hosts can govern one generated grouped subtree without enumerating every exact behavior id, exact behavior-id rules still beat broader prefixes while longer prefixes beat shorter ones through the stable narrower-behavior-scope basis, and the suppression/override runtime catalogs plus snapshot now keep the configured prefix arrays and decisive selection-basis truth visible directly — issue #483; filtered hosting/runtime suites 260/260 plus package-surface tests 2/2 (Sprint 36)
  • ENG-058-T165 behavior-id-prefix grouped-operator parity across publication groups and authoring policies: targeted ASP.NET Core hosting coverage now explicitly proves that the exact-versus-prefix shorthand governance story from BehaviorIdPrefixes flows through /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-authoring-policies, and the matching snapshot answers, including per-authoring-style grouped summaries where broader prefix rules stay visible as matched-only suppression or override outcomes beside narrower exact winners — issue #484; filtered hosting/runtime suites 4/4 (Sprint 36)
  • ENG-058-T166 behavior-id-prefix skipped-governance parity across grouped REST operator surfaces: targeted ASP.NET Core hosting coverage now explicitly proves that prefix-targeted suppression and override rules still surface as skipped outcomes when they match an explicit module-DSL behavior subtree that did not opt into host governance, keeping /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-authoring-policies, direct runtime catalogs, and snapshot aligned on skipped rule ids and summaries instead of falsely implying a selector miss — issue #485; filtered hosting/runtime suites 4/4 (Sprint 36)
  • ENG-058-T167 inline grouped generated REST module helper with preserved module ownership: Cephalon.Behaviors.Http now exposes RestBehaviorEngineBuilderExtensions.AddGeneratedRestBehaviorModuleGroups<TMarker>() so hosts can keep the MapGeneratedProfileGroups(...) path low-code without a dedicated module class; the helper still materializes a real module, delegates to the same grouped generated projection/publication-group/governance/runtime-catalog pipeline, lets the common overload derive the grouped generated root prefix from the inline module id while preserving explicit behaviorIdPrefix and ModuleDescriptor overloads when identity or metadata should differ, and now reuses the same fail-fast dot-separated prefix validation across grouped generated helper entry points — issue #486; targeted hosting/runtime tests 5/5 plus package-surface tests 1/1 (Sprint 36)
  • ENG-058-T168 behavior-backed REST module starter template: Cephalon.TemplatePack now ships cephalon-rest-behavior-module so module authors can start directly from RestBehaviorModuleBase plus a profiled starter behavior mapped through MapProfile<TBehavior>() instead of beginning from the generic IRestModule path and migrating later; the new starter keeps package-manifest output aligned, demonstrates localized behavior-backed REST ownership with the recommended module-owned DSL, and extends template-pack smoke coverage to install and generate the new starter alongside the existing blueprint and module templates — issue #487; targeted template-pack tests 3/3 (Sprint 36)
  • ENG-058-T169 REST docs closeout posture and compatibility guidance: the remaining adoption-facing REST docs now describe the shipped engine-first module-owned baseline as a settled strategy rather than an active feature roadmap, steer new behavior-backed public APIs toward cephalon-rest-behavior-module plus RestBehaviorModuleBase, align compatibility guidance with the shipped REST authoring/governance/runtime contract, and record that any future new publication sources remain deferred unless they preserve the same runtime-truth pipeline — issue #488; docs-only alignment review, no automated tests (Sprint 36)
  • ENG-058-T170 align scaffolded REST apps with behavior-backed module ownership: Cephalon.Scaffolding, Cephalon.TemplatePack, and the shipped blueprint samples now keep REST-enabled public starter modules on RestBehaviorModuleBase.ConfigureRestBehaviors(...).MapProfile<TBehavior>() instead of ModuleBase plus IEndpointModule; REST-enabled scaffold/template outputs now add Cephalon.Behaviors.Http, generated README guidance now points teams at the module-owned behavior-backed public REST baseline, and tooling coverage now locks that starter path while cephalon-rest-module and Cephalon.ReferenceModule.Operations remain the generic non-behavior path — issue #489; targeted tooling tests 11/11 (Sprint 36)
  • ENG-058-T171 host-governed preserved implicit-query fallback for explicit shorthand withdrawals: Cephalon.Abstractions now exposes RestEndpointOverrideActionKind.PreserveImplicitQueryFallback plus PreserveImplicitQueryFallback on REST override contracts, Cephalon.AspNetCore now binds RestApi:Overrides:*:PreserveImplicitQueryFallback and surfaces that declared-versus-applied action through the runtime override catalogs, and Cephalon.Behaviors.Http now allows merge-mode explicit query-binding withdrawals on non-body methods when a winning override intentionally preserves the remaining source query surface so candidate/published BindingFallbackMode truth stays aligned with runtime behavior — issue #490; filtered hosting/runtime suites 271/271 plus package-surface tests 151/151 (Sprint 36)
  • ENG-058-T172 REST projection-governance benchmark and release guardrails: Cephalon.Benchmarks now adds RestEndpointProjectionGovernanceBenchmarks.BuildMapGovernedRestCatalogs as the first engine-first ASP.NET Core REST startup/materialization lane for generated/profile/DSL precedence, shorthand-only authoring-policy enforcement, grouped generated ownership, suppression and override selection, explicit .ApiVersion(...) group authority, and preserved implicit query fallback; Cephalon.Behaviors.SourceGen now emits BehaviorRestProfileDescriptor.PreserveImplicitQueryFallback with the correct named argument casing so source-generated shorthand metadata stays buildable; and scripts/validate-release.ps1, benchmark docs, README guidance, the guardrail catalog, plus a shared in-process benchmark smoke config now keep that REST lane and the shipped hot-path guardrail catalog in the default release-validation posture — issue #491; focused REST benchmark run plus guardrail validation (Sprint 36)
  • ENG-058-T173 context-aware grouped generated REST configuration with preserved module ownership: Cephalon.Behaviors.Http now exposes derived-prefix-aware IRestBehaviorModuleBuilder.MapGeneratedProfileGroups(...) and matching RestBehaviorEngineBuilderExtensions.AddGeneratedRestBehaviorModuleGroups<TMarker>(...) overloads so one owning module or inline helper can configure each derived generated group with awareness of its exact generated behavior-id prefix; Cephalon now keeps per-branch API-version, tag, and governance-scope conventions low-code while preserving the same sourcegen-first grouped generated projection, behavior-module-generated authoring style, publication-group, governance, and runtime-catalog path instead of forcing manual group enumeration or inventing a new publication source — issue #492; filtered projection/runtime suites 273/273 plus package-surface tests 151/151 (Sprint 36)
  • ENG-058-T174 request-time REST feature-flag boundaries with preserved published runtime truth: Cephalon.Abstractions now extends RestEndpointRuntimeDescriptor with ordered RequiredFeatureFlagIds plus OriginalRequiredFeatureFlagIds, extends REST override contracts with RequiredFeatureFlagIds plus ClearRequiredFeatureFlags, and adds the matching override action kinds; Cephalon.AspNetCore now exposes RequireFeatureFlag(...), RequireFeatureFlags(...), and ClearRequiredFeatureFlags() for REST endpoints, evaluates those boundaries at request time through IFeatureToggle while preserving the active host environment in the HTTP evaluation context, and keeps /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot.RestEndpoints aligned with the same effective-versus-original feature-boundary truth; Cephalon.Behaviors.Http now carries that same feature-boundary governance through shorthand candidate projection and published endpoint materialization so feature-only no-op matches stay selected-only while real rewrites surface applied override provenance — issue #502; filtered hosting/runtime suites 283/283 plus package-surface tests 157/157 (Sprint 36)
  • ENG-058-T175 behavior-level feature-flag execution with preserved module ownership and runtime truth: Cephalon.Abstractions now extends behavior topology with ordered RequiredFeatureFlagIds plus SourceModuleId, adds IBehaviorTopologyBuilder.RequireFeatureFlag(...) / RequireFeatureFlags(...), and exposes BehaviorFeatureDisabledException; Cephalon.Behaviors now preserves those feature gates through owned-registration module identity, source-generated topology literals, shared IFeatureToggle evaluation middleware, and runtime-surface metadata so BehaviorRuntimeContributor can report both feature-gated behavior counts and per-behavior ownership truth; Cephalon.Behaviors.Http now projects the same gates through module-owned REST helpers plus JSON-RPC with truthful 404 / -32004 behavior, while messaging bindings treat disabled executions as skipped instead of retryable failures — issue #503; targeted composition tests 44/44 plus hosting tests 2/2 plus package-surface tests 157/157 (Sprint 36)

Exit criteria:

  • behaviors compose across multiple transports and patterns through a single dispatch model
  • transport bindings stay additive through companion packages
  • pattern execution strategies are selectable per behavior through configuration
  • source generator catches mismatches at build time rather than runtime

Phase 10: Non-relational provider baseline

Section titled “Phase 10: Non-relational provider baseline”

Status: done

Goal: prove the companion-pack data provider pattern across all major non-relational store categories without changing Cephalon.Engine or Cephalon.Abstractions.

Delivered:

  • 9 non-relational provider families shipped across Sprints 25–31:
    • MongoDB (document-store) — Sprint 25, 599/599 tests
    • Redis (key-value-store) — Sprint 26, 607/607 tests
    • Neo4j (graph-store) — Sprint 27, 615/615 tests
    • Cassandra (wide-column-store) — Sprint 28, 624/624 tests
    • ClickHouse (analytics-store) — Sprint 29, 632/632 tests
    • Elasticsearch (search-store) — Sprint 30, 640/640 tests
    • OpenSearch (search-store) — Sprint 30
    • Qdrant (vector-store) — Sprint 31, 648/648 tests
    • NATS (ledger-store) — Sprint 31
  • each provider family delivers both Cephalon.Data.{Provider} and Cephalon.EventSourcing.{Provider} companion packages (18 packages total)
  • full component-guide documentation for all 18 packages
  • test assembly split into 4 focused assemblies (Infrastructure Phase 2): Cephalon.Tests.Composition (327), Cephalon.Tests.Hosting (200), Cephalon.Tests.Tooling (121)

Exit criteria:

  • every major store category (document, key-value, graph, wide-column, analytics, search, vector, ledger) has a Cephalon-supported IOutbox/IInbox/IEventStore implementation
  • no changes to Cephalon.Engine or Cephalon.Abstractions were required
  • all companion packs follow the same module/registration/capability pattern established by Cephalon.Data.EntityFramework

Cross-cutting follow-through: Database topology and durable audit history

Section titled “Cross-cutting follow-through: Database topology and durable audit history”

Status: in progress

Goal: separate physical database role topology, migration targeting, and durable audit-history routing from the logical Engine:Data app-model slice so one Cephalon codebase can move between single-database, split read/write, dedicated outbox, and dedicated history layouts through configuration and additive companion packs.

Target: Sprint 31–33

Planned deliverables:

  • ENG-060 engine-owned Engine:Databases topology contract with named roles such as Write, Read, and History
  • runtime introspection for active database roles and topology answers through a dedicated catalog plus /engine/snapshot
  • ENG-061 role-aware relational follow-through so Cephalon.Data.EntityFramework consumes database-role topology instead of inventing a separate physical-layout model
  • migration targeting that references named roles, keeps startup apply explicit, and treats bundle/script-based deployment as the production path
  • ENG-062 durable audit-history follow-through that keeps Cephalon.Audit narrow while letting a first provider-backed store target a named database role
  • ENG-063 durable audit-history reader, retention, and operator-surface follow-through on top of the first provider-backed store
  • ENG-064 durable audit-history export follow-through on top of the same provider-backed store
  • ENG-066 engine-owned database-role catalog and operator surface on top of the raw topology contract

Current truth:

  • the initial ENG-060 baseline is now shipped: Engine:Databases projects into EngineSettings, AppProfile.Databases, /engine/databases, /engine/app-model, and /engine/snapshot
  • ENG-061 is now shipped: Cephalon.Data.EntityFramework consumes the engine-owned write and optional read roles directly, exposes role and migration metadata through the runtime surface, and can execute startup schema apply for those registered DbContext roles through a generic-host hosted service
  • ENG-062 is now shipped: Cephalon.Audit.EntityFramework consumes Engine:Audit:History plus the selected engine-owned database role named by Engine:Audit:History:DatabaseRole, publishes durable audit-store metadata, and proves the topology in the showcase sample with dedicated write, read, and history databases for Docker-backed runs while still allowing isolated in-memory role overrides for zero-setup local and test runs
  • ENG-063 is now shipped: durable audit history now also includes Engine:Audit:History:Retention, a host-agnostic IAuditHistoryReader, /engine/audit-history, and showcase-facing audit-history endpoints over the same durable store
  • ENG-064 is now shipped: durable audit history now also includes Engine:Audit:History:Export, a host-agnostic IAuditHistoryExporter, /engine/audit-history/export, and showcase-facing NDJSON export endpoints over the same durable store
  • ENG-065 is now shipped: dependent Outbox / History roles can explicitly reuse write through UseRole, and runtime metadata now reports requested versus resolved roles for the first truthful role-reference baseline
  • ENG-066 is now shipped: the engine now exposes a first-class resolved database-role catalog through IDatabaseRoleCatalog, /engine/database-roles, /engine/database-roles/{databaseRoleId}, and snapshot.DatabaseRoles, including co-location, consumers, and audit-history metadata
  • ENG-067 is now shipped: the engine now exposes a first-class database-migration catalog through IDatabaseMigrationCatalog, /engine/database-migrations, /engine/database-migrations/{databaseMigrationId}, and snapshot.DatabaseMigrations, while the showcase sample now keeps the same surfaces active outside Docker through unique in-memory fallback roles and keeps separate write, read, and history migration targets truthful for Docker-backed runs
  • ENG-068 is now shipped: the engine-owned database-role catalog now carries live provider-contributed health and migration diagnostics, dependent UseRole targets can inherit resolved-role runtime truth, and the migration catalog now also carries provider-added deploy-time command templates through DatabaseMigrationCommandDescriptor; Cephalon.Data.EntityFramework publishes both live probe metadata and bundle/script/update guidance, the command descriptor now also carries typed operator metadata for tool/category/working-directory fields so consumers do not have to infer those reusable semantics only from metadata keys, DatabaseMigrationDescriptor now carries a typed RecommendedExecutionOrder so operator playbooks can reuse one engine-owned migration sequence, and the same descriptor now also mirrors resolved-role runtime truth through typed role-health, role-migration, and observed-at fields so hosts do not need metadata-only parsing for stable engine-owned answers. The showcase sample now keeps that truth visible end to end through the runtime snapshot plus /api/v1/showcase/system/database-topology, including sample-level operator insights that point back to the raw engine routes, richer migration-command guidance in /showcase, explicit migration runtime notes in the operator projection, additive repo-root runnable commands for the showcase sample, an ordered sample migration playbook driven by the engine-published order hints, a top-level sample readiness summary, an ordered operator action plan, /api/v1/showcase/system/database-topology/brief as a shareable Markdown operator handoff, and /api/v1/showcase/system/database-topology/handoff as a downloadable self-describing package with a package README plus machine-readable manifest without redefining the engine contract
  • ENG-086 is now shipped: Engine:Databases:Runtime plus AppProfile.Databases.Runtime now expose RoleProbeFreshnessSeconds, role-resolution merges keep shared and role-specific freshness overrides truthful across direct roles and dependent UseRole targets, Cephalon.Data.EntityFramework now uses that engine-owned contract to cache probe results with explicit probeSource, probeFreshnessOrigin, probeFreshUntilUtc, and probeAgeSeconds metadata while invalidating cached answers when migration runtime state changes, and the showcase sample now keeps that live-versus-cached truth visible in /api/v1/showcase/system/database-topology plus /showcase without inventing sample-only rules
  • ENG-087 is now shipped: the engine-owned database-role contract now also exposes a typed DatabaseRoleProbeDescriptor through DatabaseRoleRuntimeDescriptor.Probe plus DatabaseRoleDescriptor.Probe, Cephalon.Data.EntityFramework now projects stable cache/freshness/source timing through that typed surface while keeping runtime metadata for additive provider details and compatibility, and the showcase sample now consumes the typed probe contract directly in its operator projection/UI instead of parsing stable probe* metadata keys locally
  • ENG-088 is now shipped: Cephalon.Abstractions now exposes an engine-owned database-topology operational snapshot contract, Cephalon.Engine now publishes /engine/database-topology plus snapshot.DatabaseTopology as the canonical operator posture summary, advisory, and ordered action-plan surface across role health, migration status, and production-guidance completeness, and the showcase sample now consumes that engine-owned answer directly for readiness and core advisories while keeping read-model drift/backlog follow-through sample-specific
  • ENG-089 is now shipped: the showcase sample now consumes the engine-owned database-topology action-plan contract directly instead of rebuilding engine role or migration remediation locally, preserves stable action categories plus source role and migration ids in the operator projection/UI/brief, and the docs plus package-surface coverage now describe that shared contract truthfully
  • ENG-090 is now shipped: Cephalon.Abstractions now exposes DatabaseMigrationOperationalPlaybook, DatabaseMigrationOperationalStep, and IDatabaseMigrationOperationalPlaybookProvider, Cephalon.Engine now publishes /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook as the canonical ordered migration answer over the lower-level migration catalog, and the showcase sample now consumes that engine-owned playbook directly while keeping repo-root runnable command adaptation and read-model follow-through sample-specific instead of re-deriving migration sequencing locally
  • ENG-091 is now shipped: the engine-owned database-role catalog now exposes stable physical-target identity plus physical co-location, the engine-owned migration playbook plus topology posture now expose coordination counts, per-step partner targets, and shared-target warning/action guidance when pending or failed logical migration work spans one physical database, and the showcase sample now consumes that engine-owned shared-database truth directly in its operator projection, browser UI, Markdown brief, and handoff package
  • ENG-092 is now shipped: DatabaseMigrationOperationalPlaybook now also carries engine-owned physical-target execution groups with aggregate status, grouped migration ids, coverage counts, and shared-target coordination hints, Cephalon.Engine now projects that grouped answer through /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook, and the showcase sample now consumes that grouped engine-owned answer directly in its operator projection, browser UI, Markdown brief, and handoff package
  • ENG-093 is now shipped: DatabaseMigrationOperationalExecutionGroup now also carries grouped production and manual command sets through DatabaseMigrationOperationalExecutionGroupCommand, Cephalon.Engine now projects that grouped command answer through /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook, and the showcase sample now consumes that grouped engine-owned command answer directly in its operator projection, browser UI, Markdown brief, and handoff package
  • ENG-094 is now shipped: DatabaseMigrationOperationalExecutionGroup now also carries combined production and manual command-batch templates through DatabaseMigrationOperationalExecutionGroupCommandBatch, Cephalon.Engine now projects that combined batch answer through /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook, and the showcase sample now consumes that combined engine-owned batch answer directly in its operator projection, browser UI, Markdown brief, and handoff package
  • ENG-069 is now shipped: host-agnostic event-dispatch runtime descriptor and state contracts now live in Cephalon.Abstractions, /engine/snapshot now carries EventDispatchRuntimes plus EventDispatchStates, ASP.NET Core now exposes /engine/event-dispatch-runtimes and /engine/event-dispatches, and the showcase sample now wires Cephalon.Eventing.Wolverine so the official managed dispatch path is visible end to end through the new operator surfaces
  • ENG-070 is now shipped: the engine now carries first-class outbox dispatch-policy answers through OutboxDescriptor.DispatchPolicy plus IOutboxDispatchPolicyCatalog, /engine/outboxes now distinguishes disabled, consumer-managed, and runtime-managed ownership truthfully, managed dispatch runtimes explicitly declare their owned outbox ids, and the eventing/Wolverine surfaces plus showcase sample now stay consistent with the same policy answer end to end
  • ENG-071 is now shipped: dispatch-runtime descriptors now carry a canonical aggregate Summary, /engine/event-dispatch-runtimes plus snapshot.EventDispatchRuntimes now expose that live-enriched answer directly, the wolverine-adapter and shared eventing runtime surfaces reuse the same summary instead of re-aggregating dispatch state independently, and MongoDB, Redis, Elasticsearch, and OpenSearch now join Entity Framework in exposing IEventDispatchStore for staged outboxes so the managed-dispatch contract is no longer relational-only
  • ENG-072 is now shipped: Neo4j and Qdrant now also expose provider-native IEventDispatchStore baselines for staged outboxes, so graph-store and vector-store workloads join the same consumer-managed or adapter-managed dispatch path without relaying through a relational bridge, while Cassandra, ClickHouse, and NATS remained explicit storage-model follow-through work at that point rather than hidden parity gaps
  • ENG-073 is now shipped: NATS JetStream KV now also exposes a provider-native IEventDispatchStore baseline for staged outboxes by persisting mutable staged-message records in the same bucket, so ledger-store workloads join the same consumer-managed or adapter-managed dispatch path while Cassandra and ClickHouse remained explicit storage-model follow-through work at that point
  • ENG-074 is now shipped: Cassandra now also exposes a provider-native IEventDispatchStore baseline for staged outboxes by combining the authoritative outbox_messages row with a deterministic message-sharded outbox_pending_dispatch eligibility table, so wide-column workloads join the same consumer-managed or adapter-managed dispatch path without relaying through a relational bridge while ClickHouse remains the one deliberate storage-model follow-through gap
  • ENG-075 is now shipped: ClickHouse now stays explicit about the opposite truth, keeping its ReplacingMergeTree outbox staging-only while publishing DispatchPolicy.PolicyId = unsupported with ExecutionMode = disabled plus provider-specific reason metadata so /engine/outboxes, event-dispatches, and the runtime snapshot stop collapsing that deliberate storage-model boundary into a generic “not configured” answer
  • the remaining phase-10 work is now broader provider consumption where the storage model stays truthful, broader role graphs beyond UseRole -> write, additional managed-dispatch providers beyond the current Wolverine path, bundle/script generation or execution orchestration, richer provider-native telemetry beyond the current live-versus-cached probe baseline, and replay follow-through plus richer export formats for durable history

Exit criteria:

  • a consumer app can keep one Cephalon codebase and move between shared-db and split-db layouts through config and additive pack wiring
  • database topology, migration targeting, and durable audit-history state are all introspectable instead of hidden in host startup code
  • provider packs stay additive because the engine owns the role and migration contract instead of one pack becoming the de facto source of truth
  • optional convenience DbContext base classes, if they appear later, remain thin DX helpers rather than the primary engine contract

Updated priority order as of April 18, 2026:

  1. start phase 7 with ENG-033 cross-platform validation and shell parity so the shipped build, test, publish, and install flows stop assuming Windows-specific shell behavior
  2. follow immediately with ENG-034 first-run adoption and environment-doctor work so external teams have one clear install, validation, and runtime-smoke path
  3. ENG-035 is now complete, so Cephalon’s package-manifest, trust, provenance, and runtime-introspection story is exercised outside this repository through the staged external package flow
  4. ENG-036 is now complete, so Docker Desktop / WSL users have a reproducible modular monolith sample deployment that preserves the shipped runtime, health, and OTLP collector path
  5. ENG-037 is now complete, so newly scaffolded apps carry the documented package-source bootstrap needed to restore, build, and follow the container path without repo-only package-feed knowledge
  6. ENG-038 is now complete, so newly scaffolded apps also carry a deterministic folder-publish profile and a validated published-output smoke path that runs outside the repo tree once the supported package source is seeded or repointed
  7. ENG-039 is now complete, so newly scaffolded apps also carry Linux systemd install assets and a validated WSL verification path that closes the self-hosted service-manager gap after publish
  8. ENG-040 is now complete, so newly scaffolded apps also carry Windows Service install assets and a validated install-preview path that closes the self-hosted Windows service-manager gap after publish
  9. ENG-041 is now complete, so newly scaffolded apps also carry IIS install assets and a validated ANCM/published-output preview path that closes the hosted Windows deployment gap after publish
  10. ENG-042 is now complete, so newly scaffolded apps also carry Azure App Service ZIP-deploy assets and a validated run-from-package preview path that closes the hosted Azure deployment gap after publish
  11. ENG-043 is now complete, so newly scaffolded apps also carry Azure Container Apps source-deploy assets and a validated Dockerfile plus Azure CLI preview path that closes the hosted Azure container deployment gap from the generated app root
  12. ENG-044 is now complete, so newly scaffolded apps also carry Kubernetes manifest/apply assets and a validated Dockerfile plus kubectl kustomize preview path that closes the platform-neutral cluster deployment gap from the generated app root
  13. ENG-045 is now complete, so newly scaffolded apps also carry provider-neutral container-image build/tag/push assets and a validated local-registry smoke path that closes the remaining image-publication gap between local Dockerfile validation and hosted container deployment targets
  14. ENG-097 is now complete, so the repo has an explicit .NET 11 readiness lane, a dedicated readiness script, truthful deployment-mode claim language, and a higher-SDK workflow path before any default-target migration is considered
  15. keep phase 6 in later / Todo until another explicit cloud or platform target becomes adoption-driven beyond the shipped self-hosted, Azure Monitor, AWS, GCP, Huawei Cloud, Alibaba Cloud, Oracle Cloud, Red Hat OpenShift, DigitalOcean, VMware Tanzu, Kubernetes, Cloudflare/custom-provider guidance, Grafana Cloud, and New Relic baseline
  16. future solution-level expansion only when an explicit adoption scenario needs it
  17. open phase 8 with ENG-046, ENG-047, and ENG-048 so ids, structured config sections, and host-agnostic contracts freeze before package implementations or template defaults drift
  18. follow with ENG-049 and ENG-050 so Cephalon proves a relational Entity Framework plus CQRS plus outbox plus eventing golden path before it claims broader provider breadth
  19. then deliver ENG-051, ENG-052, and ENG-053 so identity/authorization, multi-tenancy/audit, and CLI/scaffolding/template/sample follow-through land on the same frozen phase-8 contract
  20. then deliver ENG-055 and ENG-056 so benchmarks, validation, docs, XML comments, and reference-doc alignment prove the phase-8 claims before the repo widens the public story
  21. ENG-054 Track 1 (non-relational providers) and ENG-057 (event-sourcing follow-through) are now complete; keep hybrid-cloud, service-mesh, and serverless expansion as explicit later slices until an adopter needs them beyond the proven golden path
  22. open phase 11 with resilience foundation (circuit breaker, retry/timeout/bulkhead, rate limiting) plus onion-architecture and anti-corruption-layer pattern descriptors so production microservice deployments have configuration-driven fault tolerance
  23. follow with phase 12 for migration and advanced coordination (strangler fig, saga choreography, BFF pattern, feature flags, durable execution) so enterprise adoption and distributed coordination stories are complete
  24. then phase 13 for next-generation patterns (cell-based architecture, data mesh, CDC) when explicit adoption scenarios justify the investment

Status: in progress

Goal: add production-critical resilience infrastructure so consumer microservices can handle cascading failures, transient faults, and traffic spikes through configuration-driven policies.

Target: Sprint 36–37

Shipped baseline:

  • onion-architecture pattern descriptor in BuiltInPatterns.cs for taxonomy completeness alongside Clean and Hexagonal
  • anti-corruption-layer pattern descriptor in BuiltInPatterns.cs for explicit DDD integration boundary support
  • Engine:Resilience configuration section covering contract-first Retry, Timeout, CircuitBreaker, Bulkhead, and RateLimiting policy intent
  • projection of that requested contract into EngineSettings, AppProfile.Resilience, /engine/app-model, and /engine/resilience
  • ASP.NET Core public-HTTP rate limiting wired through Microsoft.AspNetCore.RateLimiting, /engine/rate-limiting, and snapshot.RateLimitingPolicies with operator/docs route exclusions
  • additive Engine:Resilience:RateLimiting:Overrides modeling projected into AppProfile.Resilience so ASP.NET Core hosts can resolve endpoint-scoped behavior and transport overrides with truthful runtime/OpenAPI answers
  • built-in ASP.NET Core GraphQL route split across /graphql, /graphql/schema, /graphql-sse, and /graphql-ws under the same ApiRoutes:Prefixes contract, with /engine/rate-limiting now publishing transportKind, transportSemantics, enforcementMoment, and longLivedTransportIds for long-lived transport policies
  • shared behavior-dispatch resilience now enforces retry, timeout, circuit-breaker, bulkhead, and rate limiting through Cephalon.Behaviors, /engine/behavior-resilience, and snapshot.BehaviorResiliencePolicies
  • additive Engine:Resilience:BehaviorExecution:Overrides modeling projected into AppProfile.Resilience so Cephalon.Behaviors can resolve behavior-scoped, transport-scoped, and behavior+transport retry/timeout/circuit-breaker/bulkhead/rate-limiting overrides with explicit disable answers and truthful /engine/behavior-resilience plus REST/OpenAPI status metadata
  • showcase sample configuration now demonstrates the same resilience contract in grouped Configurations/Engine/Resilience/* files

Remaining follow-through:

  • broader non-REST transport-native resilience-envelope semantics beyond the current ASP.NET Core public-HTTP plus shared behavior-dispatch 429/503 baseline for rate limiting, timeout, and circuit breaker
  • capabilities: resilience.circuit-breaker, resilience.retry, resilience.timeout, resilience.bulkhead, resilience.rate-limiting

Exit criteria:

  • a consumer app can configure per-behavior resilience policies through Engine:Resilience without writing custom middleware
  • the requested and effective resilience contract remains introspectable through AppProfile.Resilience, /engine/resilience, /engine/rate-limiting, and /engine/snapshot
  • default and scoped behavior-execution timeout, circuit-breaker, bulkhead, and rate-limiting policies can be configured through Engine:Resilience plus Engine:Resilience:BehaviorExecution:Overrides without custom dispatch glue
  • health probes and circuit breakers compose together to prevent cascading failures
  • ASP.NET Core HTTP rate limiting can be configured per behavior or per transport

Phase 12: Migration and Advanced Coordination

Section titled “Phase 12: Migration and Advanced Coordination”

Status: in progress

Goal: expand the distributed coordination story with choreography-based sagas, incremental migration support, progressive delivery, and durable execution foundations.

Target: Sprint 38–40 follow-through

Planned deliverables:

  • strangler-fig pattern descriptor plus the first host-agnostic runtime-contract baseline (IStranglerFigRouteContributor, IStranglerFigRuntimeCatalog, IStranglerFigRouter, /engine/strangler-fig, and snapshot.StranglerFigRoutes) for incremental migration from legacy systems are now shipped
  • the first configuration-driven strangler-fig migration-policy overlay is now also shipped through Engine:Migration:StranglerFig, IStranglerFigMigrationRuntimeCatalog, /engine/strangler-fig/runtime, and snapshot.StranglerFigRoutePolicies
  • the first ASP.NET Core host-level cutover runtime is now also shipped through Engine:Migration:StranglerFig:AspNetCore, /engine/strangler-fig/cutover, and /engine/strangler-fig/cutover/resolve, with rooted local selections rewritten in-process, absolute HTTP or HTTPS selections redirected or proxied, and unsupported selected endpoints rejected truthfully with 502 while broader traffic-manager or ingress follow-through remains planned
  • backend-for-frontend pattern plus the host-agnostic client-binding runtime, the client-aware REST filtering runtime, and the first REST documentation/materialization baseline (BackendForFrontendClientBindingDescriptor, IBackendForFrontendRuntimeCatalog, IBackendForFrontendRestRuntimeCatalog, BackendForFrontendRestDocumentRuntimeDescriptor, /engine/backend-for-frontend, /engine/backend-for-frontend/rest-endpoints, /engine/backend-for-frontend/rest-documents, and the matching snapshot fields) are now shipped, while broader non-REST frontend-materialization remains later follow-through
  • the first host-agnostic saga choreography baseline is now also shipped through IBehaviorTopologyBuilder.AsSagaChoreography(), source-generated saga-choreography literals, ISagaChoreographyPublisher, SagaChoreographyPublication, SagaChoreographyStepResult, InMemorySagaChoreographyPublisher, ChoreographySagaExecutionStrategy, capability behaviors.saga-choreography, and advisory ABT-005; the explicit eventing bridge follow-through is now also shipped through Cephalon.Eventing.Behaviors, AddBehaviorEventingBridge(), capability eventing.behaviors.saga-choreography, and the saga-choreography-bridges runtime surface; the first higher-level authoring-helper follow-through is now also shipped through ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, SagaChoreographyStepResult<TOutput>, and typed JSON publication helpers on SagaChoreographyPublication; the first static choreography runtime/operator follow-through is now also shipped through SagaChoreographyRuntimeDescriptor, ISagaChoreographyRuntimeCatalog, snapshot.SagaChoreographies, and /engine/saga-choreographies; the first live publication-state follow-through is now also shipped through SagaChoreographyPublicationRuntimeState, ISagaChoreographyPublicationRuntimeStateCatalog, snapshot.SagaChoreographyPublicationStates, and /engine/saga-choreographies/runtime*; and the module-backed capabilities behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state are now also shipped when AddBehaviorPatterns() activates the shared runtime surfaces
  • the first feature-flag runtime baseline is now shipped through FeatureFlagDescriptor, FeatureFlagTargetingDescriptor, IFeatureToggle, IFeatureFlagRuntimeCatalog, IFeatureFlagContributor, Engine:Features, /engine/features, /engine/features/{featureFlagId}/evaluate, and snapshot.FeatureFlags; the generic external-provider bridge baseline is now also shipped through FeatureFlagProviderBindingDescriptor, FeatureFlagProviderEvaluationResult, IFeatureFlagProvider, FeatureFlagDescriptor.ProviderBindings, Engine:Features:Flags:*:ProviderBindings, and engine.AddFeatureFlagProvider(...); the first shared behavior-execution follow-through is also now shipped through BehaviorTopologyDescriptor.RequiredFeatureFlagIds, IBehaviorTopologyBuilder.RequireFeatureFlag(...), BehaviorFeatureDisabledException, shared behavior-pipeline evaluation, source-generated topology literals, and runtime metadata, while provider-specific companion-pack integrations and any future capability publication remain later follow-through
  • the first durable-execution baseline is now also shipped through IBehaviorTopologyBuilder.AsDurableExecution(), source-generated durable-execution literals, IDurableExecution<TState>, IDurableExecution<TInput, TState, TOutput>, DurableExecutionState<TState>, DurableExecutionStepResult<TOutput>, DurableExecutionStrategy, capability behaviors.durable-execution, and compatibility rule ABT-006; the first durable runtime/operator follow-through is now also shipped through DurableExecutionRuntimeDescriptor, IDurableExecutionRuntimeCatalog, /engine/durable-executions, and snapshot.DurableExecutions, and the first durable live-state/failure-posture follow-through is now also shipped through DurableExecutionRuntimeState, IDurableExecutionRuntimeStateCatalog, /engine/durable-executions/runtime, and snapshot.DurableExecutionStates; the first durable timer/signal coordination follow-through is now also shipped through DurableExecutionPendingTimer, DurableExecutionPendingSignal, /engine/durable-executions/runtime/timers*, and /engine/durable-executions/runtime/signals*; the first durable compensation-helper follow-through is now also shipped through DurableExecutionCompensationAction, /engine/durable-executions/runtime/compensations*, and additive compensation-action metadata on DurableExecutionStepResult<TOutput> plus DurableExecutionRuntimeState, while any future auto-executing durable recovery remains later follow-through

Exit criteria:

  • a consumer app can migrate incrementally from a legacy system using the strangler fig router
  • sagas can coordinate through events (choreography) in addition to state (orchestration)
  • feature flags can gate behavior, module, transport, environment, tenant, subject, or tag-scoped availability through IFeatureToggle and Engine:Features
  • durable execution workflows survive process restarts through replay semantics backed by IEventStore
  • operators can inspect active durable workflows, ownership, transports, rollout gates, typed replay contract shape, and current per-stream durable posture through engine-owned runtime catalogs

Status: in progress

Goal: add differentiation-grade patterns that position CephalonEngine for the next generation of distributed application architecture.

Target: Sprint 40–41

Shipped baseline:

  • ENG-120 now ships the first cell-based architecture boundary baseline through the built-in cell-based-architecture profile, CellBoundaryDescriptor, ICellBoundaryContributor, ICellBoundaryCatalog, engine.AddCellBoundary(...), /engine/cells*, snapshot.CellBoundaries, and the cell-boundaries technology runtime surface; active boundaries now auto-select the profile while preserving module ownership in one runtime truth

  • ENG-121 now extends that same phase-13 runtime truth with CellRouteDescriptor, ICellRouteContributor, ICellRouteCatalog, engine.AddCellRoute(...), /engine/cell-routes*, snapshot.CellRoutes, and the cell-routes technology runtime surface; active routes validate against the same boundary/module ownership graph instead of introducing a second host-only traffic registry

  • ENG-122 now extends that same phase-13 runtime truth with CellHealthIsolationDescriptor, ICellHealthIsolationContributor, ICellHealthIsolationCatalog, engine.AddCellHealthIsolation(...), /engine/cell-health-isolations*, snapshot.CellHealthIsolations, and the cell-health-isolations technology runtime surface; active health-isolation answers validate module ownership against the same boundary graph instead of inventing a host-only health partition registry

  • ENG-123 now extends that same phase-13 runtime truth with Engine:Cells:TrafficAutomation, CellSettings, CellTrafficAutomationSettings, CellTrafficAutomationRouteSettings, ICellTrafficAutomationRuntimeCatalog, /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and the cell-traffic-automations technology runtime surface; effective automation answers stay derived from the existing route plus health-isolation graph so module ownership remains authoritative instead of inventing a second host-only traffic manager

  • ENG-124 now ships the first data mesh runtime baseline through IDataProduct<T>, DataProductDescriptor, IDataProductCatalog, IDataProductContributor, IDataProductRegistry, /engine/data-products*, and snapshot.DataProducts; queryable data-product ownership now stays module-backed through sourceModuleId, domainId, contractId, and mode instead of requiring a host-only catalog or provider-specific runtime surface

  • ENG-125 now ships the first CDC capture runtime baseline through ICdcCapture, CdcCaptureDescriptor, ICdcCaptureCatalog, ICdcCaptureContributor, ICdcCaptureRegistry, /engine/cdc-captures*, and snapshot.CdcCaptures; CDC capture ownership now stays module-backed through sourceModuleId, provider, sourceId, outboxId, mode, eventFormat, resourceIds, and metadata while engine composition validates referenced source modules and outboxes instead of inventing a host-only sync registry

  • ENG-126 now extends that same phase-13 runtime truth with CdcCaptureRuntimeState, ICdcCaptureRuntimeStateCatalog, /engine/cdc-captures/runtime*, and snapshot.CdcCaptureStates; live CDC runtime answers now stay descriptor-backed, carry latest-plus-total capture metrics plus checkpoint/error metadata, and can merge linked OutboxDispatchState from the existing event-dispatch runtime truth instead of inventing a second host-only publish-state registry

  • ENG-127 now extends that same phase-13 runtime truth again with CdcCaptureFreshnessStatus, CdcCaptureLagStatus, CdcCapturePublicationStatus, and the matching typed runtime-state fields on CdcCaptureRuntimeState; provider/runtime reporters can now publish freshness windows, lag posture, pending source-change counts, and pending publication counts while the shared catalog applies a conservative linked-dispatch publication overlay through the same /engine/cdc-captures/runtime* plus snapshot.CdcCaptureStates surface

  • ENG-128 now adds the first shared CDC hosted-execution substrate through CdcCaptureExecutionResult, stable ICdcCapture.CdcCaptureId plus IOutbox.OutboxId bindings, the data.cdc.execution capability, the data-cdc-capture-flow execution graph, the data-cdc-capture-pump hosted execution, and shared in-process outbox staging/reporting through the existing execution/runtime-story surfaces without replacing module-owned capture descriptors or runtime-state truth

  • ENG-129 now closes the shared replay-safe CDC checkpoint-commit follow-through through CdcCaptureExecutionAcknowledgement, ICdcCaptureAcknowledger, the acknowledge-cdc-progress node inside data-cdc-capture-flow, post-stage acknowledgement plus acknowledgerServiceType metadata on success, and truthful failureKind = acknowledgement plus pending checkpoint/change-id metadata when provider acknowledgement fails after staging

  • ENG-130 now adds the first CDC execution-runtime catalog baseline through CdcCaptureExecutionRuntimeDescriptor, CdcCaptureExecutionRuntimeSummary, ICdcCaptureExecutionRuntimeCatalog, /engine/cdc-capture-runtimes*, and snapshot.CdcCaptureExecutionRuntimes; the shared data-cdc-capture-pump runtime now publishes one operator-facing ownership/topology answer with linked capture ids plus an aggregate summary derived from the shared CDC runtime-state catalog instead of leaving runner topology implicit in host-specific execution metadata

  • ENG-131 now closes the first CDC execution-ownership binding baseline through CdcCaptureExecutionBindingDescriptor, ExecutionBinding on CdcCaptureDescriptor plus CdcCaptureRuntimeState, deterministic capture-to-runtime binding resolution, /engine/cdc-captures/execution-runtimes/{executionRuntimeId}, /engine/cdc-captures/runtime/execution-runtimes/{executionRuntimeId}, and shared-pump filtering that executes only captures effectively owned by data-cdc-capture-pump

  • ENG-132 now adds the first external execution-runtime declaration baseline through first-class execution runtime ownership/topology fields, inverse GetByExecutionRuntimeId(...) lookups on the shared CDC catalogs, DataRuntimeOptions.CdcExecutionRuntimes, CdcCaptureExecutionRuntimeOptions, and the same /engine/cdc-capture-runtimes* plus inverse capture/runtime drill-down routes, so configured external-managed or provider-native runtimes can join the shared operator story without pretending Cephalon hosts them

  • ENG-133 now proves the first concrete provider-native CDC runner through Cephalon.Data.MongoDB, MongoDbChangeStreamCaptureOptions, mongodb-change-stream-capture-flow, mongodb-change-stream-capture-pump, resume-token checkpoints, and preserved authored sourceModuleId truth with separate contributorModuleId metadata when the provider pack contributes on another module’s behalf

  • ENG-134 now adds the first out-of-process CDC live-reporting baseline through CdcCaptureRuntimeObservation, ICdcCaptureExecutionRuntimeReportSink, DataRuntimeOptions.EnableExternalCdcRuntimeReporting, and POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, so external execution runtimes can publish live posture back into the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces while capture ownership still stays grounded in ExecutionBinding

  • ENG-135 now extends the first cell traffic-automation baseline with provider-aware and edge-aware targeting through first-class providerId plus edgeNodeIds, additive Engine:Cells:TrafficAutomation defaults and route overrides, derived materialization posture, /engine/cell-traffic-automations/providers/{providerId}, /engine/cell-traffic-automations/edge-nodes/{edgeNodeId}, and the same snapshot.CellTrafficAutomations plus cell-traffic-automations technology surface instead of inventing a second traffic registry

  • ENG-136 now adds the first provider-managed cell traffic materializer baseline through ICellTrafficAutomationProviderMaterializer, CellTrafficAutomationProviderMaterializationResult, CellTrafficAutomationProviderMaterializationStates, startup reconciliation over the shared CellTrafficAutomationRuntimeCatalogSnapshot, and additive providerMaterializerId plus providerMaterializationState/ObservedAtUtc/Error fields on CellTrafficAutomationRuntimeDescriptor, so provider-managed or provider-and-edge-managed routes can publish selected materializer ownership and latest reconciliation posture through the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface without inventing a second traffic-materialization registry

  • ENG-137 now adds the first edge-runtime cell traffic materializer baseline through ICellTrafficAutomationEdgeMaterializer, CellTrafficAutomationMaterializationResult, CellTrafficAutomationMaterializationStates, startup reconciliation over the shared CellTrafficAutomationRuntimeCatalogSnapshot, and the first concrete edge-runtime-materializer in Cephalon.Edge, so edge-managed or provider-and-edge-managed routes can publish selected edge materializer ownership and latest reconciliation posture through the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface without inventing a second traffic-materialization registry

  • ENG-138 now hardens richer multi-provider reconciliation on that same shared traffic catalog through Priority plus CanMaterialize(...) selection inputs on provider and edge materializers, highest-priority match resolution with ambiguous tie failures, additive materializationState/materializationObservedAtUtc/materializationError on CellTrafficAutomationRuntimeDescriptor, and selection-rationale metadata such as matching-candidate counts plus state breakdown, so provider-managed, edge-managed, and provider-and-edge-managed routes publish requested, selected, and observed truth on the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface without inventing a second reconciliation registry

  • ENG-139 now proves the first provider-specific control-plane materializer on that same shared traffic catalog through Cephalon.Edge.KubernetesGateway, KubernetesGatewayTrafficMaterializerOptions, KubernetesGatewayTrafficRouteOptions, AddKubernetesGatewayTrafficMaterializer(...), and the kubernetes-gateway-traffic-materializations technology surface; selected provider-managed routes can now publish deterministic Kubernetes Gateway API Gateway plus HTTPRoute intent metadata such as providerRouteId, parent/backend references, controller identity, and truthful statusSource = configured-intent placeholders on the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-based-architecture runtime story without inventing a second control-plane registry or pretending the pack already performs live cluster reconciliation

  • ENG-140 now layers the first live Kubernetes Gateway API reconciliation baseline on top of that same projected-intent pack: Cephalon.Abstractions now ships ICellTrafficAutomationMaterializationReportSink, Cephalon.Engine now lets provider and edge observers merge live materialization answers back into the same shared CellTrafficAutomationRuntimeCatalogSnapshot, and Cephalon.Edge.KubernetesGateway now adds KubernetesGatewayTrafficObservationOptions plus observe-only mode so selected routes can publish live Gateway/HTTPRoute condition truth, freshness windows, and drift posture through /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations without a second registry

  • ENG-141 now hardens that same pack with the first Kubernetes Gateway apply-and-reconcile baseline: KubernetesGatewayTrafficObservationModes now adds apply-and-reconcile, configured-intent now keeps the shared provider state truthfully pending, Cephalon.Edge.KubernetesGateway now applies only owned HTTPRoute resources while treating Gateway as a pre-provisioned dependency, and the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations surfaces now publish ownership-aware write results together with reconciled Gateway plus HTTPRoute status instead of inventing a second control-plane registry

  • ENG-142 now proves the same provider-materializer seam against a second control-plane family through Cephalon.Edge.Traefik, TraefikTrafficMaterializerOptions, TraefikIngressRouteOptions, TraefikMiddlewareReferenceOptions, AddTraefikTrafficMaterializer(...), and the traefik-ingressroute-traffic-materializations technology surface; selected provider-managed routes can now publish deterministic Traefik IngressRoute intent metadata such as providerRouteId, entry points, match rules, middleware references, backend service references, and TLS posture on the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-based-architecture runtime story without inventing a second control-plane registry or pretending the pack already performs live Traefik reconciliation

  • ENG-143 now hardens broader control-plane ownership lifecycle truth on that same shared traffic catalog through CellTrafficAutomationOwnershipStates, CellTrafficAutomationDependencyStates, CellTrafficAutomationDriftStates, CellTrafficAutomationLifecycleActions, and derived materialization.* lifecycle summaries; Cephalon.Engine now seeds and aggregates requested versus owned versus conflict posture across provider and edge dimensions while Cephalon.Edge, Cephalon.Edge.KubernetesGateway, and Cephalon.Edge.Traefik now publish the same ownership/dependency/drift/lifecycle-action vocabulary on the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces instead of inventing provider-local lifecycle taxonomies

  • ENG-144 now layers the first live Traefik observation baseline on top of that same projected-intent pack: Cephalon.Edge.Traefik now adds TraefikTrafficObservationModes, TraefikTrafficObservationOptions, and opt-in observe-only polling over Traefik IngressRoute, Middleware, TLSOption, backend Service, and TLS Secret resources so the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations surfaces can publish route existence, ownership, dependency, drift, and freshness truth without inventing a second control-plane registry or pretending the pack already performs owned writes

  • ENG-145 now hardens that same Traefik pack with the first apply-and-reconcile ownership loop: TraefikTrafficObservationModes now adds apply-and-reconcile, configured intent now stays truthfully pending, Cephalon.Edge.Traefik now creates or replaces only owned IngressRoute resources while treating Middleware, TLSOption, backend Service, and TLS Secret resources as pre-provisioned dependencies, and the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations surfaces now publish ownership-aware ingressRouteWriteAction metadata together with reconciled live Traefik observation without inventing a second control-plane registry

  • ENG-146 now hardens provider-native lifecycle execution across both shipped control-plane packs: Cephalon.Edge.KubernetesGateway and Cephalon.Edge.Traefik now classify external unmanaged resources separately from stale or incomplete Cephalon ownership metadata, lazily resolve active owners through ICellTrafficAutomationRuntimeCatalog, preserve previous-owner metadata during transfer-aware adoption, and keep merged create / replace / transfer lifecycle truth visible on the same shared automation and provider-specific surfaces instead of collapsing successful reconciliation back to observe

  • ENG-147 now closes the first cleanup-sweep follow-through on that same runtime story: KubernetesGatewayTrafficObservationOptions and TraefikTrafficObservationOptions now expose opt-in EnableCleanupSweep, both provider packs now run namespace-scoped delete or prune sweeps over stale transferred or orphaned provider-owned routes only during apply-and-reconcile, and the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces now publish additive providerMaterialization.cleanup* and provider cleanup summaries without inventing a second lifecycle registry

  • ENG-148 now adds the second provider-native CDC implementation and first relational proof on that same shared CDC runtime story: Cephalon.Data.SqlServer now contributes SqlServerDataOptions, SqlServerCdcCaptureOptions, sqlserver-cdc-capture-flow, sqlserver-cdc-capture-pump, provider-native SQL change-table polling, durable startLsn|seqval|operation checkpoints, and the same /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing a second relational CDC registry

  • ENG-149 now hardens external CDC runtime reporting on that same shared runtime story: CdcCaptureRuntimeObservation now carries stable ReportId, declared execution runtimes can now set ObservationStaleAfterSeconds plus RejectOutOfOrderReports, Cephalon.Data now treats matching duplicate report ids as idempotent retries while rejecting configured out-of-order submissions, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now publish LastReportId plus typed ObservationFreshness without inventing a second watchdog registry

  • ENG-152 now deepens external and edge-aware CDC execution topologies on that same shared runtime story: CdcCaptureRuntimeObservation plus CdcCaptureExecutionReport now carry ReporterId plus EdgeNodeId, declared execution runtimes can now set ReporterLeaseSeconds, RejectConflictingReporterIds, and EdgeNodeIds, Cephalon.Data now enforces active reporter-lease ownership plus declared edge-node allow-lists while stamping reporter/edge metadata, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now publish LastReporterId, ActiveReporterId, ReporterLeaseExpiresAtUtc, ObservedEdgeNodeIds, and LastEdgeNodeId without inventing a second topology coordinator

  • ENG-153 now adds the third provider-native CDC implementation and the first logical-replication streaming proof on that same shared runtime story: Cephalon.Data.Postgres now contributes PostgresDataOptions, PostgresLogicalReplicationCaptureOptions, postgresql-logical-replication-capture-flow, postgresql-logical-replication-capture-pump, provider-native pgoutput streaming, publication/table validation, optional slot creation, durable slotName|commitLsn|transactionEndLsn checkpoints, and the same /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing a PostgreSQL-specific CDC registry

  • ENG-154 now hardens that same PostgreSQL runner with publication and slot lifecycle truth: PostgresLogicalReplicationCaptureOptions now exposes RecreateSlotIfInvalidated, provider-native transport execution now validates slot type/plugin/database ownership plus invalidated or WAL-loss posture, inactive invalidated slots can now be recreated intentionally, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces now publish additive slotLifecycleState, slotLifecycleAction, slotResumeMode, slotRestartLsn, slotConfirmedFlushLsn, slotWalStatus, slotInvalidationReason, and provider-specific failure-kind answers without inventing a PostgreSQL-only lifecycle registry

  • ENG-155 now adds richer external and edge-aware CDC failover plus takeover truth on that same shared runtime story: Cephalon.Abstractions now ships CdcCaptureReporterCoordinationStates plus CdcCaptureReporterCoordinationStatus, CdcCaptureRuntimeState and CdcCaptureExecutionRuntimeSummary now expose first-class ReporterCoordination, Cephalon.Data now records rejected conflicts plus accepted reporter takeovers after lease expiry on the shared runtime-state catalog, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, and snapshot surfaces now publish active-owner, previous-owner, lease-expiry, takeover, and conflicting-reporter posture without inventing a second topology coordinator

  • ENG-156 now hardens that same shared external CDC runtime story with richer multi-reporter reconciliation: Cephalon.Abstractions now ships CdcCaptureReporterParticipantRoles plus CdcCaptureReporterParticipantStatus, CdcCaptureReporterCoordinationStatus now carries ReporterParticipants, HasStandbyReporters, and HasRejectedReporters, and Cephalon.Data now keeps accepted previous owners visible as standby participants plus rejected conflicts visible as rejected participants on the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, and snapshot surfaces without inventing a second coordination registry

  • ENG-157 now hardens that same shared external CDC runtime story with stable takeover and degraded-posture semantics: Cephalon.Abstractions now ships CdcCaptureReporterCoordinationIssueReasons plus CdcCaptureReporterTakeoverStates, CdcCaptureReporterCoordinationStatus now carries TakeoverState, DegradedReason, RequiresTakeover, and HasCompletedTakeover, and Cephalon.Data now derives awaiting-takeover, rejected-reporter-conflict, and multiple-active-reporters reasons on both per-capture runtime-state and execution-runtime summary surfaces without inventing a second operator taxonomy

  • ENG-158 now adds the fourth provider-native CDC implementation and the first MySQL binlog proof on that same shared runtime story: Cephalon.Data.MySql now contributes MySqlDataOptions, MySqlBinlogCaptureOptions, mysql-binlog-capture-flow, mysql-binlog-capture-pump, provider-native row-event reads, durable binlogFile|position checkpoints, bounded initial-position resolution, and the same /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing a MySQL-specific CDC registry

  • ENG-159 now hardens that same MySQL provider-native runner with lifecycle and resume truth: MySqlBinlogCaptureOptions now supports ExpectedSourceServerUuid, the Cephalon-managed checkpoint table now keeps additive SourceServerUuid, SourceServerId, GtidExecutedSet, BinlogFormat, and BinlogRowImage metadata, and the shared runtime-state plus execution-runtime surfaces now publish binlogLifecycleState, binlogLifecycleAction, sourceServerIdentityState, sourceServerIdentityAction, checkpoint source-server metadata, and GTID observe-only answers while distinguishing lifecycle failures such as binary-logging-disabled, source-server-mismatch, and checkpoint-binlog-unavailable without inventing a MySQL-only lifecycle registry

  • ENG-160 now broadens that same shared external CDC runtime story with reporter rejoin and stale-conflict cleanup: CdcCaptureReporterCoordinationStatus now exposes additive participant-count helpers, Cephalon.Data now clears stale rejected-conflict evidence after later accepted reports, and completed takeovers now stop surfacing previous owners as standby participants once the replacement reporter reaffirms lease ownership while preserving historical previousReporterId, lease-expiry, and takeover timestamps on the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, and snapshot surfaces without inventing a second coordinator

  • ENG-161 now adds the fifth provider-native CDC implementation and the first Oracle redo-log proof on that same shared runtime story: Cephalon.Data.Oracle now contributes OracleDataOptions, OracleLogMinerCaptureOptions, oracle-logminer-capture-flow, oracle-logminer-capture-pump, provider-native committed-only LogMiner execution, bounded SCN-window plus redo-log selection, durable commitScn|changeScn|rsId|ssn checkpoints, and the same /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing an Oracle-specific CDC registry

  • ENG-162 now hardens that same Oracle provider-native runner with lifecycle and resume truth: OracleLogMinerCaptureOptions now supports ExpectedDatabaseId, ExpectedDatabaseUniqueName, and ResumeFromEarliestAvailableScnIfCheckpointUnavailable, the Cephalon-managed checkpoint table now keeps additive DatabaseId, DatabaseUniqueName, ResetLogsChangeNumber, ArchiveLogMode, and SupplementalLogDataMin metadata, and the shared runtime-state plus execution-runtime surfaces now publish databaseIdentity*, archiveLogLifecycle*, and checkpoint-provenance answers while distinguishing lifecycle failures such as archive-log-disabled, database-identity-mismatch, checkpoint-database-mismatch, checkpoint-scn-unavailable, and checkpoint-scn-ahead-of-current without inventing an Oracle-only lifecycle registry

  • ENG-163 now hardens that same shared external and edge-aware CDC runtime story with operator-story drill-down routes and catalog filters: ICdcCaptureRuntimeStateCatalog plus ICdcCaptureExecutionRuntimeCatalog now expose reporter-id, edge-node-id, coordination-state, and degraded-reason filters, and ASP.NET Core now publishes those same queries through /engine/cdc-captures/runtime/reporters/{reporterId}, /engine/cdc-captures/runtime/edge-nodes/{edgeNodeId}, /engine/cdc-captures/runtime/reporter-coordination/{coordinationState}, /engine/cdc-captures/runtime/reporter-coordination/issues/{degradedReason}, /engine/cdc-capture-runtimes/reporters/{reporterId}, /engine/cdc-capture-runtimes/edge-nodes/{edgeNodeId}, /engine/cdc-capture-runtimes/reporter-coordination/{coordinationState}, and /engine/cdc-capture-runtimes/reporter-coordination/issues/{degradedReason} without inventing a second coordination registry

  • ENG-164 now adds the first external managed-connector capture implementation on that same shared runtime story: Cephalon.Data.Debezium now contributes DebeziumDataOptions, DebeziumConnectorOptions, and DebeziumCaptureOptions, binds Debezium-managed captures to external execution runtimes with executionOwnership = external-managed plus executionTopology = managed-connector, and makes POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports available whenever Debezium connectors are configured so operator flows can project real Debezium/Kafka Connect style runtime truth through the same /engine/cdc-*, /engine/runtime-story, and snapshot surfaces without inventing a Debezium-only registry

  • ENG-165 now hardens that same Debezium managed-connector runtime story with observe-only lifecycle and reconciliation truth: DebeziumConnectorOptions now supports ManagementMode plus ExpectedTaskCount, Cephalon.Data.Debezium now normalizes raw connector and task report metadata into stable debezium* lifecycle or reconciliation answers, and the shared execution-runtime catalog now promotes runtime-scoped Debezium metadata back onto /engine/cdc-capture-runtimes* and snapshot without inventing a Debezium-only lifecycle registry

  • ENG-166 now adds richer CDC operator-story rollups on that same shared external and edge-aware runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeReporterCoordinationRollup plus CdcCaptureReporterCoordinationBreakdownEntry, CdcCaptureExecutionRuntimeSummary now carries additive ReporterCoordinationRollup, and Cephalon.Data now derives runtime-level coordination-state breakdowns, degraded-reason breakdowns, active/standby/rejected reporter ids, and degraded capture ids back onto /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes without inventing a second coordination registry or Debezium-only rollup surface

  • ENG-167 now hardens that same shared external and edge-aware runtime story with declared-versus-reported coverage truth: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeReportingCoverageStates plus CdcCaptureExecutionRuntimeReportingCoverageStatus, CdcCaptureExecutionRuntimeSummary now carries additive ReportingCoverage plus HasUnreportedDeclaredCaptures / HasFullCaptureCoverage, and Cephalon.Data now derives ReportedCdcCaptureIds plus runtime-level not-bound, unreported, partially-reported, and fully-reported posture only from captures that have submitted real observations back onto /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes without inventing a second coverage registry

  • ENG-168 now closes the next shared follow-through on that same external and edge-aware runtime story with aggregate remediation summaries plus runtime-first drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeRemediationStates, CdcCaptureExecutionRuntimeRemediationCategories, and CdcCaptureExecutionRuntimeRemediationStatus, CdcCaptureExecutionRuntimeSummary now carries additive Remediation plus RequiresRemediation / HasBlockingRemediation, and Cephalon.Data now derives runtime-level ready, attention, and blocked posture plus active remediation categories from resolved capture ownership and the existing shared runtime-state story back onto /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes without inventing a second remediation registry

  • ENG-169 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector governance posture plus runtime-first governance drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorGovernanceStates, CdcCaptureExecutionRuntimeManagedConnectorGovernanceCategories, CdcCaptureExecutionRuntimeManagedConnectorGovernanceActionIds, and CdcCaptureExecutionRuntimeManagedConnectorGovernanceStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorGovernance, Cephalon.Data now derives runtime-level observe-only, future-control-plane, and out-of-policy posture plus governance categories from merged managed-connector metadata, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/governance/{governanceState} plus /engine/cdc-capture-runtimes/governance/categories/{governanceCategory} without inventing a Debezium-only governance registry

  • ENG-170 now closes the next shared follow-through on that same external and edge-aware runtime story with desired-versus-observed managed-connector drift posture plus runtime-first drift drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDriftStates, CdcCaptureExecutionRuntimeManagedConnectorDriftCategories, CdcCaptureExecutionRuntimeManagedConnectorDriftActionIds, and CdcCaptureExecutionRuntimeManagedConnectorDriftStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDrift, Cephalon.Data now derives runtime-level unknown, in-sync, and drifted posture plus drift categories from declared-versus-reported task topology and managed-connector identity metadata, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/drift/{driftState} plus /engine/cdc-capture-runtimes/drift/categories/{driftCategory} without inventing a Debezium-only drift registry

  • ENG-171 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector action-planning posture plus runtime-first action drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorActionPlanStates, CdcCaptureExecutionRuntimeManagedConnectorActionPlanCategories, CdcCaptureExecutionRuntimeManagedConnectorActionPlanActionIds, and CdcCaptureExecutionRuntimeManagedConnectorActionPlanStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorActionPlan, Cephalon.Data now derives runtime-level observe, waiting, action-required, and blocked posture plus action ids from merged remediation, governance, and drift truth, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/action-plans/{actionPlanState} plus /engine/cdc-capture-runtimes/actions/{actionId} without inventing a Debezium-only action-planning registry

  • ENG-172 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector write-path readiness posture plus runtime-first readiness drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessStates, CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessCategories, and CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorWritePathReadiness, Cephalon.Data now derives runtime-level not-applicable, deferred, not-ready, ready, and blocked posture plus readiness categories from merged coverage, remediation, governance, drift, and action-planning truth, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/write-path-readiness/{readinessState} plus /engine/cdc-capture-runtimes/write-path-readiness/categories/{readinessCategory} without inventing a Debezium-only readiness registry

  • ENG-173 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector preflight posture plus runtime-first preflight drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorPreflightStates, CdcCaptureExecutionRuntimeManagedConnectorPreflightCategories, CdcCaptureExecutionRuntimeManagedConnectorPreflightOperationIds, and CdcCaptureExecutionRuntimeManagedConnectorPreflightStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorPreflight, Cephalon.Data now derives runtime-level not-applicable, deferred, not-ready, ready, and blocked posture plus preflight categories and operation ids from merged coverage, remediation, governance, drift, action-planning, and write-path-readiness truth, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/preflight/{preflightState} plus /engine/cdc-capture-runtimes/preflight/categories/{preflightCategory} and /engine/cdc-capture-runtimes/preflight/operations/{operationId} without inventing a Debezium-only preflight registry

  • ENG-174 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector dry-run posture plus runtime-first dry-run drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDryRunStates, CdcCaptureExecutionRuntimeManagedConnectorDryRunCategories, CdcCaptureExecutionRuntimeManagedConnectorDryRunOperationIds, and CdcCaptureExecutionRuntimeManagedConnectorDryRunStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDryRun, Cephalon.Data now derives runtime-level not-applicable, deferred, blocked, no-op, and would-change posture plus dry-run categories and operation ids from merged coverage, remediation, governance, drift, action-planning, write-path-readiness, and preflight truth, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/dry-runs/{dryRunState} plus /engine/cdc-capture-runtimes/dry-runs/categories/{dryRunCategory} and /engine/cdc-capture-runtimes/dry-runs/operations/{operationId} without inventing a Debezium-only dry-run registry

  • ENG-175 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector execution-intent posture plus runtime-first execution-intent drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentSources, and CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionIntent, Cephalon.Data now derives runtime-level not-applicable, deferred, blocked, operator-action, requires-approval, and ready-to-execute posture plus execution-intent categories, operation ids, and confidence-source truth from merged dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/execution-intents/{executionIntentState} plus /engine/cdc-capture-runtimes/execution-intents/categories/{executionIntentCategory} and /engine/cdc-capture-runtimes/execution-intents/operations/{operationId} without inventing a Debezium-only execution planner

  • ENG-176 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector execution-approval and safety-gating posture plus runtime-first execution-approval drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalSources, and CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionApproval, Cephalon.Data now derives runtime-level not-applicable, auto-blocked, policy-blocked, approval-required, approval-ready, and auto-eligible posture plus execution-approval categories, operation ids, safety-gating source truth, and explicit-approval posture from merged dry-run, execution-intent, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/execution-approvals/{executionApprovalState} plus /engine/cdc-capture-runtimes/execution-approvals/categories/{executionApprovalCategory} and /engine/cdc-capture-runtimes/execution-approvals/operations/{operationId} without inventing a Debezium-only approval registry

  • ENG-177 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector write-path command-envelope posture plus runtime-first command-envelope drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeStates, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandEnvelope, Cephalon.Data now derives runtime-level not-applicable, blocked, operator-only, approval-gated, and engine-ready posture plus command-envelope categories, operation ids, source truth, target identity, deterministic command fingerprints, and safety flags from merged execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-envelopes/{commandState} plus /engine/cdc-capture-runtimes/command-envelopes/categories/{commandCategory} and /engine/cdc-capture-runtimes/command-envelopes/operations/{operationId} without inventing a Debezium-only execution registry

  • ENG-178 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector command-issuance posture plus runtime-first command-issuance drill-downs: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceStates, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandIssuance, Cephalon.Data now derives runtime-level not-applicable, blocked, operator-only, accepted, rejected, and issued posture plus command-issuance categories, operation ids, issuance source truth, deterministic issuance fingerprints, and safety flags from merged command-envelope, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-issuances/{issuanceState} plus /engine/cdc-capture-runtimes/command-issuances/categories/{issuanceCategory} and /engine/cdc-capture-runtimes/command-issuances/operations/{operationId} without inventing a Debezium-only issuance registry

  • ENG-179 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector provider execution-adapter posture plus shared command-execution request and result semantics: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterSources, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterStatus, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionRequest, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionResult, ICdcCaptureExecutionRuntimeManagedConnectorExecutionAdapter, and ICdcCaptureExecutionRuntimeManagedConnectorCommandExecutor, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionAdapter, Cephalon.Data now derives runtime-level not-applicable, blocked, operator-only, unavailable, and ready posture plus execution-adapter categories, operation ids, adapter identity, deterministic adapter fingerprints, and provider-ready safety flags from merged command-issuance, command-envelope, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, Cephalon.Data.Debezium now proves the first provider adapter by translating shared pause/resume/restart/delete intent into Debezium or Kafka Connect REST command shape, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/execution-adapters/{executionAdapterState} plus /engine/cdc-capture-runtimes/execution-adapters/categories/{executionAdapterCategory} and /engine/cdc-capture-runtimes/execution-adapters/operations/{operationId} together with additive POST /engine/cdc-capture-runtimes/{executionRuntimeId}/commands/{operationId} on the existing shared route family without inventing a Debezium-only control-plane registry

  • ENG-180 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector execution outcome/history posture on the existing shared command lane: CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionStates now also ships stable unrecorded, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionResult now carries additive AttemptId, RecordedAtUtc, IsUnrecorded, and HasRecordedOutcome, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandExecution, Cephalon.Data now records latest command-execution posture plus bounded recent history from the shared POST /engine/cdc-capture-runtimes/{executionRuntimeId}/commands/{operationId} request/result lane, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandExecutionState(...), GetByManagedConnectorCommandExecutionOperationId(...), and GetManagedConnectorCommandExecutionHistory(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-executions/{executionState} plus /engine/cdc-capture-runtimes/command-executions/operations/{operationId} and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-executions without inventing a Debezium-only command journal or second coordinator

  • ENG-181 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector retry/idempotency posture on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandRetryStates, CdcCaptureExecutionRuntimeManagedConnectorCommandRetryCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandRetryOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandRetrySources, and CdcCaptureExecutionRuntimeManagedConnectorCommandRetryStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandRetry, Cephalon.Data now derives runtime-level not-applicable, not-needed, duplicate, cooldown, retry-blocked, operator-only, and retry-eligible posture plus retry categories, operation ids, fingerprint matching, cooldown windows, and latest-attempt context from merged command-execution history, command-issuance, execution-adapter, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandRetryState(...), GetByManagedConnectorCommandRetryCategory(...), and GetByManagedConnectorCommandRetryOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-retries/{retryState} plus /engine/cdc-capture-runtimes/command-retries/categories/{retryCategory} and /engine/cdc-capture-runtimes/command-retries/operations/{operationId} without inventing a Debezium-only retry registry

  • ENG-182 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector retry-execution policy posture on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyStates, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyCategories, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyOperationIds, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicySources, and CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorRetryExecutionPolicy, Cephalon.Data now derives runtime-level not-applicable, not-needed, cooldown, manual-approval, policy-blocked, operator-only, and background-retry-disabled posture plus policy categories, operation ids, retry fingerprints, cooldown windows, and latest-attempt context from merged command-retry, command-execution history, command-issuance, execution-adapter, execution-approval, command-envelope, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorRetryExecutionPolicyState(...), GetByManagedConnectorRetryExecutionPolicyCategory(...), and GetByManagedConnectorRetryExecutionPolicyOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/retry-execution-policies/{policyState} plus /engine/cdc-capture-runtimes/retry-execution-policies/categories/{policyCategory} and /engine/cdc-capture-runtimes/retry-execution-policies/operations/{operationId} without inventing a Debezium-only retry-policy registry

  • ENG-183 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector bounded command-journal posture on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandJournalStates, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandJournalStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandJournal, Cephalon.Data now derives runtime-level not-applicable, empty, bounded, truncated, cooldown-active, duplicate-evidence-present, and insufficient-for-automation posture plus journal categories, operation ids, source truth, retained-versus-recorded history counts, cooldown windows, fingerprint matching, and latest-versus-oldest retained attempt context from merged command-execution history, command-retry, retry-execution policy, command-issuance, execution-adapter, execution-approval, command-envelope, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage answers, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandJournalState(...) and GetByManagedConnectorCommandJournalCategory(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-journals/{journalState} plus /engine/cdc-capture-runtimes/command-journals/categories/{journalCategory} and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-journal without inventing a Debezium-only durable journal or second coordinator

  • ENG-184 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector automatic background retry execution on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionOperationIds, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionSources, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionStatus, and CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionInvocationSources, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorAutomaticRetryExecution, Cephalon.Data now derives runtime-level not-applicable, disabled, blocked, eligible, and completed posture plus automatic-retry categories, operation ids, matching safety-context reuse flags, cooldown windows, retry and execution fingerprints, latest automatic-attempt metadata, and invocation-source truth from merged retry-execution-policy, command-journal, command-retry, and command-execution history, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorAutomaticRetryExecutionState(...), GetByManagedConnectorAutomaticRetryExecutionCategory(...), and GetByManagedConnectorAutomaticRetryExecutionOperationId(...), the shared data pack now runs the bounded opt-in automatic retry lane through EnableManagedConnectorAutomaticRetryExecution, ManagedConnectorAutomaticRetryPollingIntervalSeconds, and ManagedConnectorAutomaticRetryHostedService, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/automatic-retries/{automaticRetryState} plus /engine/cdc-capture-runtimes/automatic-retries/categories/{automaticRetryCategory} and /engine/cdc-capture-runtimes/automatic-retries/operations/{operationId} without inventing a Debezium-only retry loop, durable distributed scheduler, or second coordinator

  • ENG-185 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector automatic background retry coordination on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationStates, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationCategories, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationSources, and CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorAutomaticRetryCoordination, Cephalon.Data now derives runtime-level not-applicable, single-node, uncoordinated, lease-held, lease-missing, conflicted, and operator-only posture plus coordination categories, active-reporter and coordination-owner identity, reporter-lease timing, source truth, and CanExecuteOnCurrentNode from merged execution ownership, execution topology, reporter coordination, automatic-retry execution, retry-execution policy, and command-journal truth, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorAutomaticRetryCoordinationState(...), GetByManagedConnectorAutomaticRetryCoordinationCategory(...), and GetByManagedConnectorAutomaticRetryCoordinationOwnerId(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through the host-level ManagedConnectorAutomaticRetryCoordinationOwnerId policy, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/automatic-retry-coordinations/{coordinationState} plus /engine/cdc-capture-runtimes/automatic-retry-coordinations/categories/{coordinationCategory} and /engine/cdc-capture-runtimes/automatic-retry-coordinations/owners/{ownerId} without inventing a durable distributed scheduler, second coordination registry, or Debezium-only multi-node retry loop

  • ENG-186 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector durable retry-journal posture on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityStates, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilitySources, and CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandJournalDurability, Cephalon.Data now derives runtime-level not-applicable, in-memory-only, persisted, recovered, recovery-failed, and persistence-failed posture plus durability categories, persistence path, persisted-versus-recovered timestamps, retained-versus-recorded history counts, and persisted or recovered history flags from merged command-journal, automatic-retry execution, automatic-retry coordination, and file-backed history-store truth, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandJournalDurabilityState(...) and GetByManagedConnectorCommandJournalDurabilityCategory(...), the shared data pack now exposes ManagedConnectorCommandJournalPersistencePath so ManagedConnectorCommandExecutionHistoryStore can persist and recover bounded retry evidence across host restart, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-journal-durability/{durabilityState} plus /engine/cdc-capture-runtimes/command-journal-durability/categories/{durabilityCategory} and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-journal-durability without inventing a second journal registry, durable distributed scheduler, or Debezium-only persistence subsystem

  • ENG-187 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector distributed retry lease and cross-node idempotency hardening on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseStates, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseCategories, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseSources, and CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDistributedRetryLease, Cephalon.Data now derives runtime-level not-applicable, single-node, lease-held, lease-missing, lease-conflicted, idempotent-safe, idempotency-risk, and operator-only posture plus coordination-owner and active-reporter identity, retry-fingerprint and bounded-history evidence, durable-store and duplicate-attempt truth, and CanExecuteAutomaticRetryOnCurrentNode from merged automatic-retry coordination, automatic-retry execution, retry-execution policy, command-journal, command-journal durability, and retained command history answers, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDistributedRetryLeaseState(...), GetByManagedConnectorDistributedRetryLeaseCategory(...), and GetByManagedConnectorDistributedRetryLeaseOwnerId(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that richer cross-node answer instead of raw coordination alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/distributed-retry-leases/{leaseState} plus /engine/cdc-capture-runtimes/distributed-retry-leases/categories/{leaseCategory}, /engine/cdc-capture-runtimes/distributed-retry-leases/owners/{ownerId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/distributed-retry-lease without inventing a second coordination registry, second retry registry, or Debezium-only multi-node retry subsystem

  • ENG-188 now closes the next shared follow-through on that same external and edge-aware runtime story with managed-connector distributed retry orchestration on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDistributedRetryOrchestration, Cephalon.Data now derives runtime-level not-applicable, disabled, operator-only, cooldown, blocked, scheduled, and completed posture plus orchestration categories, scheduler identity/kind, polling interval, owner/reporter identity, retry fingerprint, latest-attempt metadata, durable-history evidence, and CanScheduleAutomaticRetryOnCurrentNode from merged automatic-retry execution, automatic-retry coordination, retry-execution policy, command-journal durability, and distributed retry lease truth, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDistributedRetryOrchestrationState(...), GetByManagedConnectorDistributedRetryOrchestrationCategory(...), and GetByManagedConnectorDistributedRetryOrchestrationOwnerId(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that richer shared orchestration answer instead of raw lease checks, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/distributed-retry-orchestrations/{orchestrationState} plus /engine/cdc-capture-runtimes/distributed-retry-orchestrations/categories/{orchestrationCategory}, /engine/cdc-capture-runtimes/distributed-retry-orchestrations/owners/{ownerId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/distributed-retry-orchestration without inventing a second coordinator, second registry, or Debezium-only scheduler subsystem

  • ENG-189 now closes the next shared follow-through on that same external and edge-aware runtime story with richer managed-connector cross-node idempotency hardening on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCrossNodeIdempotencyHardening, Cephalon.Data now derives runtime-level not-applicable, operator-only, idempotent-safe, stale-owner-risk, duplicate-lineage-risk, and replay-window-risk posture plus hardening categories, coordination-owner and active-reporter identity, retry fingerprint, retained-lineage and automatic-attempt evidence, durable-history truth, and CanExecuteAutomaticRetryOnCurrentNode from merged automatic-retry execution, automatic-retry coordination, retry-execution policy, command-journal, command-journal durability, distributed retry lease, and retained command history answers, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCrossNodeIdempotencyHardeningState(...), GetByManagedConnectorCrossNodeIdempotencyHardeningCategory(...), GetByManagedConnectorCrossNodeIdempotencyHardeningOwnerId(...), and GetByManagedConnectorCrossNodeIdempotencyHardeningRetryFingerprint(...), the shared data pack now feeds that richer answer back into distributed retry orchestration so bounded scheduling no longer trusts raw lease truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/cross-node-idempotency-hardenings/{hardeningState} plus /engine/cdc-capture-runtimes/cross-node-idempotency-hardenings/categories/{hardeningCategory}, /engine/cdc-capture-runtimes/cross-node-idempotency-hardenings/owners/{ownerId}, /engine/cdc-capture-runtimes/cross-node-idempotency-hardenings/fingerprints/{retryFingerprint}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/cross-node-idempotency-hardening without inventing a second coordinator, second registry, or Debezium-only idempotency subsystem

  • ENG-190 now closes the next shared follow-through on that same external and edge-aware runtime story with broader managed-connector multi-node lease execution on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorMultiNodeLeaseExecution, Cephalon.Data now derives runtime-level not-applicable, operator-only, single-node, lease-executable, lease-blocked, lease-conflicted, and stale-lease-risk posture plus lease-execution categories, coordination-owner and active-reporter identity, scheduler identity/kind, polling interval, retry fingerprint, latest automatic-attempt metadata, and CanExecuteAutomaticRetryOnCurrentNode from merged automatic-retry coordination, distributed retry lease, cross-node idempotency hardening, and distributed retry orchestration truth, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorMultiNodeLeaseExecutionState(...), GetByManagedConnectorMultiNodeLeaseExecutionCategory(...), and GetByManagedConnectorMultiNodeLeaseExecutionOwnerId(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader multi-node lease-execution answer instead of distributed retry orchestration alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/multi-node-lease-executions/{leaseExecutionState} plus /engine/cdc-capture-runtimes/multi-node-lease-executions/categories/{leaseExecutionCategory}, /engine/cdc-capture-runtimes/multi-node-lease-executions/owners/{ownerId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/multi-node-lease-execution without inventing a second coordinator, second registry, or Debezium-only lease-execution subsystem

  • ENG-191 now closes the next shared follow-through on that same external and edge-aware runtime story with durable shared scheduler orchestration on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDurableSharedSchedulerOrchestration, Cephalon.Data now derives runtime-level not-applicable, disabled, operator-only, unscheduled, scheduled, lease-blocked, recovery-needed, and scheduler-conflicted posture plus scheduler categories, execution-runtime and capture identity, ownership/topology, coordination-owner and active-reporter identity, scheduler identity/kind, polling interval, retry fingerprint, latest automatic-attempt metadata, durable-history truth, and CanScheduleAutomaticRetryOnCurrentNode from merged automatic-retry coordination, command-journal durability, distributed retry orchestration, and broader multi-node lease-execution truth, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDurableSharedSchedulerOrchestrationState(...), GetByManagedConnectorDurableSharedSchedulerOrchestrationCategory(...), and GetByManagedConnectorDurableSharedSchedulerOrchestrationOwnerId(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader scheduler answer instead of broader multi-node lease-execution truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/durable-shared-scheduler-orchestrations/{schedulerState} plus /engine/cdc-capture-runtimes/durable-shared-scheduler-orchestrations/categories/{schedulerCategory}, /engine/cdc-capture-runtimes/durable-shared-scheduler-orchestrations/owners/{ownerId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/durable-shared-scheduler-orchestration without inventing a second coordinator, second registry, or Debezium-only scheduler subsystem

  • ENG-192 now closes the next shared follow-through on that same external and edge-aware runtime story with scheduler recovery and execution hardening on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorSchedulerRecoveryExecutionHardening, Cephalon.Data now derives runtime-level not-applicable, operator-only, recovery-ready, recovery-blocked, replaying, execution-hardened, and execution-risk posture plus categories, execution-runtime and capture identity, ownership/topology, coordination-owner and active-reporter identity, durable shared scheduler, broader multi-node lease-execution, distributed retry orchestration, command-journal durability, latest command-execution truth, scheduler identity/kind, polling interval, retry fingerprint, latest automatic-attempt metadata, durable-history truth, and CanExecuteAutomaticRetryOnCurrentNode from merged durable shared scheduler, broader multi-node lease-execution, distributed retry orchestration, command-journal durability, and latest execution history, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorSchedulerRecoveryExecutionHardeningState(...), GetByManagedConnectorSchedulerRecoveryExecutionHardeningCategory(...), GetByManagedConnectorSchedulerRecoveryExecutionHardeningOwnerId(...), and GetByManagedConnectorSchedulerRecoveryExecutionHardeningRetryFingerprint(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader scheduler recovery answer instead of durable shared scheduler truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/scheduler-recovery-execution-hardenings/{hardeningState} plus /engine/cdc-capture-runtimes/scheduler-recovery-execution-hardenings/categories/{hardeningCategory}, /engine/cdc-capture-runtimes/scheduler-recovery-execution-hardenings/owners/{ownerId}, /engine/cdc-capture-runtimes/scheduler-recovery-execution-hardenings/fingerprints/{retryFingerprint}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/scheduler-recovery-execution-hardening without inventing a second coordinator, second registry, or Debezium-only recovery subsystem

  • ENG-193 now closes the next shared follow-through on that same external and edge-aware runtime story with broader provider-owned write-path execution on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedWritePathExecution, Cephalon.Data now derives runtime-level not-applicable, operator-only, provider-executable, provider-blocked, provider-owned-executing, provider-owned-completed, and provider-owned-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, execution-adapter plus latest-command plus retry-policy plus automatic-retry plus lease plus scheduler plus recovery state, adapter/provider metadata, deterministic fingerprints, approval/destructive/change metadata, and CanExecuteProviderOwnedWritePathOnCurrentNode from merged provider execution-adapter, latest command-execution, retry-execution-policy, automatic background retry, distributed retry lease, durable shared scheduler, and scheduler recovery truth, ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedWritePathExecutionState(...), GetByManagedConnectorProviderOwnedWritePathExecutionCategory(...), and GetByManagedConnectorProviderOwnedWritePathExecutionOperationId(...), the shared data pack now gates both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider-owned write-path answer instead of scheduler recovery truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-write-path-executions/{providerExecutionState} plus /engine/cdc-capture-runtimes/provider-owned-write-path-executions/categories/{providerExecutionCategory}, /engine/cdc-capture-runtimes/provider-owned-write-path-executions/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-write-path-execution without inventing a second coordinator, second registry, or Debezium-only control-plane surface

  • ENG-199 now closes the next shared follow-through on that same external and edge-aware runtime story with provider-owned control-plane dependency-aware apply-and-reconcile hardening on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardening, Cephalon.Data now derives runtime-level not-applicable, operator-only, dependency-ready, dependency-blocked, dependency-degraded, apply-and-reconcile-hardened, and dependency-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader governance plus drift plus provider-owned control-plane apply-and-reconcile plus provisioning plus mutation/reconcile plus ownership plus execution-orchestration plus write-path truth, latest command plus retry-policy plus command-journal evidence, declared-versus-reported dependency identity and task-topology metadata, active reporter-lease evidence, and CanExecuteDependencyAwareApplyAndReconcileOnCurrentNode through GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningState(...), GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-control-plane-dependency-aware-apply-and-reconcile-hardenings/{hardeningState} plus /engine/cdc-capture-runtimes/provider-owned-control-plane-dependency-aware-apply-and-reconcile-hardenings/categories/{hardeningCategory}, /engine/cdc-capture-runtimes/provider-owned-control-plane-dependency-aware-apply-and-reconcile-hardenings/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-control-plane-dependency-aware-apply-and-reconcile-hardening without inventing a second coordinator, second registry, or Debezium-only dependency-hardening surface

  • ENG-200 now closes the next shared follow-through on that same external and edge-aware runtime story with provider-owned control-plane dependency-aware provisioning and mutation hardening on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardening, Cephalon.Data now derives runtime-level not-applicable, operator-only, dependency-ready, provisioning-blocked, mutation-blocked, dependency-degraded, provisioning-hardened, mutation-hardened, and dependency-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader governance plus drift plus provider-owned control-plane dependency-aware apply-and-reconcile plus apply-and-reconcile execution plus provisioning plus mutation/reconcile plus ownership plus execution-orchestration plus write-path truth, latest command plus retry-policy plus command-journal evidence, declared-versus-reported dependency identity and task-topology metadata, durable-history plus reporter-lease evidence, and CanExecuteDependencyAwareProvisioningAndMutationOnCurrentNode through GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningState(...), GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-control-plane-dependency-aware-provisioning-and-mutation-hardenings/{hardeningState} plus /engine/cdc-capture-runtimes/provider-owned-control-plane-dependency-aware-provisioning-and-mutation-hardenings/categories/{hardeningCategory}, /engine/cdc-capture-runtimes/provider-owned-control-plane-dependency-aware-provisioning-and-mutation-hardenings/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-control-plane-dependency-aware-provisioning-and-mutation-hardening without inventing a second coordinator, second registry, or Debezium-only provisioning/mutation dependency-hardening surface

  • ENG-201 now closes the next shared follow-through on that same external and edge-aware runtime story with provider-specific control-plane materializer truth on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerStates, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderSpecificControlPlaneMaterializer, Cephalon.Data now derives runtime-level not-applicable, operator-only, materializer-unavailable, materializer-ready, materializer-selected, materializer-executing, and materializer-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader provider-owned control-plane dependency-aware provisioning and mutation hardening plus apply-and-reconcile plus provisioning plus mutation/reconcile plus ownership plus execution-orchestration plus write-path truth, latest command plus retry-policy plus command-journal evidence, durable-history plus reporter-lease signals, provider-specific provider/materializer/transport/provider-surface/connector/worker identity, and CanUseProviderSpecificControlPlaneMaterializerOnCurrentNode through GetByManagedConnectorProviderSpecificControlPlaneMaterializerState(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerCategory(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerProviderId(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerProviderSurfaceId(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerId(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerConnectorId(...), and GetByManagedConnectorProviderSpecificControlPlaneMaterializerOperationId(...), Cephalon.Data.Debezium now normalizes provider-specific materializer metadata through the existing contributor plus report-sink lane, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/{materializerState} plus /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/categories/{materializerCategory}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/providers/{providerId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/provider-surfaces/{providerSurfaceId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/materializers/{materializerId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/connectors/{connectorId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-specific-control-plane-materializer without inventing a second coordinator, second registry, or Debezium-only materializer surface

  • ENG-202 now closes the next shared follow-through on that same external and edge-aware runtime story with provider-specific control-plane dependency-aware teardown and mutation-execution hardening on the existing shared command lane: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, Cephalon.Data now derives runtime-level not-applicable, operator-only, dependency-ready, teardown-blocked, mutation-execution-blocked, dependency-degraded, teardown-hardened, mutation-execution-hardened, and dependency-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader provider-specific control-plane materializer plus provider-owned control-plane dependency-aware provisioning and mutation hardening plus apply-and-reconcile plus provisioning plus mutation/reconcile plus ownership plus execution-orchestration plus write-path truth, latest command plus retry-policy plus command-journal evidence, durable-history plus reporter-lease signals, provider/materializer/transport/provider-surface/connector/worker identity, and CanExecuteDependencyAwareTeardownAndMutationExecutionOnCurrentNode through GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningState(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCategory(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningProviderId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningProviderSurfaceId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningMaterializerId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningConnectorId(...), and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/{hardeningState} plus /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/categories/{hardeningCategory}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/providers/{providerId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/provider-surfaces/{providerSurfaceId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/materializers/{materializerId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/connectors/{connectorId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardening without inventing a second coordinator, second registry, or Debezium-only teardown/mutation-execution surface

  • ENG-203 now closes the next shared provider-specific identity drill-down follow-through on that same external and edge-aware runtime story: the shared execution-runtime catalog now exposes provider-surface and connector selectors for both provider-specific materializer and provider-specific dependency-aware teardown/mutation-execution hardening posture, and ASP.NET Core publishes matching /provider-surfaces/{providerSurfaceId} plus /connectors/{connectorId} drill-downs on those same two shared route families so operators can navigate directly from Debezium Kafka Connect REST surface identity to the affected runtime without inventing a second registry or Debezium-only operator API

  • ENG-204 now hardens provider-specific worker identity normalization on that same external and edge-aware runtime story: Cephalon.Data.Debezium now falls back from raw provider metadata workerId to the stable external reporterId when normalizing provider-specific control-plane observations, the shared execution-runtime catalog now resolves the best available provider-specific worker id from normalized metadata plus active reporter truth, and both provider-specific materializer and provider-specific dependency-aware teardown/mutation-execution hardening posture now keep WorkerIdentityVisible answers truthful without inventing a Debezium-only worker registry

  • ENG-205 now closes the next provider-specific worker drill-down follow-through on that same external and edge-aware runtime story: the shared execution-runtime catalog now exposes /workers/{workerId} selectors for both provider-specific materializer and provider-specific dependency-aware teardown/mutation-execution hardening posture, and ASP.NET Core publishes those matching worker routes on the existing shared provider-specific route families so operators can navigate directly from Debezium Kafka Connect REST worker identity to the affected runtime without inventing a second registry or Debezium-only operator API

  • ENG-206 now closes the next provider-specific transport drill-down follow-through on that same external and edge-aware runtime story: the shared execution-runtime catalog now exposes /transports/{transportKind} selectors for both provider-specific materializer and provider-specific dependency-aware teardown/mutation-execution hardening posture, and ASP.NET Core publishes those matching transport routes on the existing shared provider-specific route families so operators can navigate directly from Debezium Kafka Connect REST transport identity to the affected runtime without inventing a second registry or Debezium-only operator API

  • ENG-207 now closes the next provider-specific dependency-identity drill-down follow-through on that same external and edge-aware runtime story: the shared execution-runtime catalog now exposes /connect-clusters/{connectClusterId}, /connector-classes/{connectorClass}, and /source-providers/{sourceProviderId} selectors for both provider-specific materializer and provider-specific dependency-aware teardown/mutation-execution hardening posture, and ASP.NET Core publishes those matching dependency-identity routes on the existing shared provider-specific route families so operators can navigate directly from Debezium Kafka Connect cluster/class/source identity to the affected runtime without inventing a second registry or Debezium-only operator API

  • ENG-208 now closes the next provider-specific current-node drill-down follow-through on that same external and edge-aware runtime story: the shared execution-runtime catalog now exposes current-nodes selectors for provider-specific materializer posture plus overall, teardown, and mutation-execution current-node selectors for provider-specific dependency-aware teardown/mutation-execution hardening posture, and ASP.NET Core publishes those matching routes on the existing shared provider-specific route families so operators can navigate directly from executable-versus-blocked provider-specific node posture to the affected runtime without inventing a second registry or Debezium-only operator API

    • ENG-150 now adds richer provider-native condition semantics on that same shared cell traffic runtime story: Cephalon.Abstractions now ships CellTrafficAutomationMaterializationConditionDescriptor plus stable condition dimensions/categories/states/severities, provider and edge materialization results now carry typed Conditions, CellTrafficAutomationRuntimeDescriptor now carries merged MaterializationConditions, Cephalon.Engine now derives additive materialization.*, providerMaterialization.*, and edgeMaterialization.* summaries such as conditionCount, conditionCategories, conditionStates, conditionBreakdown, and highestConditionSeverity, and Cephalon.Edge, Cephalon.Edge.KubernetesGateway, plus Cephalon.Edge.Traefik now publish stable readiness, ownership, dependency, lifecycle, and observation conditions on the existing shared plus provider-specific surfaces instead of provider-local condition vocabularies
  • ENG-151 now broadens dependency-aware teardown on that same shared cell traffic runtime story: providerMaterialization.cleanup* plus provider-specific technology surfaces now publish cleanupStrategy and primary/dependency cleanup breakdowns, Cephalon.Edge.KubernetesGateway truthfully keeps cleanup primary-only for owned HTTPRoute sweeps, and Cephalon.Edge.Traefik now extends cleanup to safe owned Middleware plus TLSOption dependents that no longer map to active projections without inventing a second lifecycle registry Remaining follow-through:

  • additional provider-specific control-plane materializers plus broader dependency-aware teardown beyond the shipped shared ownership/dependency/drift/lifecycle-action baseline, the shipped explicit external-conflict versus orphaned-transfer lifecycle semantics, the shipped typed provider-native condition taxonomy plus condition summaries, the shipped Kubernetes Gateway API configured-intent / observe-only / owned-HTTPRoute apply-and-reconcile plus primary-only cleanup breakdown baseline, and the shipped Traefik IngressRoute configured-intent / observe-only / owned-apply-and-reconcile plus safe owned Middleware/TLSOption cleanup breakdown baseline

  • additional provider-specific capture implementations plus later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through beyond the shipped command-issuance posture, shipped provider execution-adapter posture, shipped shared command-execution request/result baseline, shipped shared execution outcome/history baseline, shipped shared retry/idempotency posture, shipped shared retry-execution-policy posture, shipped shared bounded command-journal posture, shipped shared automatic background retry execution posture, shipped shared automatic background retry coordination posture, shipped shared durable command-journal posture, shipped shared distributed retry lease posture, shipped shared distributed retry orchestration posture plus orchestration drill-down filters, shipped richer shared cross-node idempotency hardening posture plus hardening drill-down filters, shipped broader shared multi-node lease-execution posture plus lease-execution drill-down filters, shipped durable shared scheduler-orchestration posture plus scheduler drill-down filters, shipped shared scheduler recovery/execution-hardening posture plus hardening drill-down filters, shipped broader shared provider-owned write-path execution posture plus write-path drill-down filters, shipped broader shared provider execution orchestration posture plus orchestration drill-down filters, shipped shared provider-owned control-plane ownership posture plus control-plane ownership drill-down filters, shipped shared provider-owned control-plane mutation/reconcile posture plus mutation/reconcile drill-down filters, shipped shared provider-owned control-plane provisioning posture plus provisioning drill-down filters, shipped shared provider-owned control-plane apply-and-reconcile execution posture plus apply-and-reconcile execution drill-down filters, shipped shared provider-owned control-plane dependency-aware apply-and-reconcile hardening posture plus hardening drill-down filters, shipped shared provider-owned control-plane dependency-aware provisioning and mutation hardening posture plus hardening drill-down filters, shipped shared provider-specific control-plane materializer posture plus state/category/provider/provider-surface/materializer/transport/connect-cluster/connector-class/source-provider/connector/worker/current-node/operation drill-down filters, and shipped shared provider-specific control-plane dependency-aware teardown and mutation-execution hardening posture plus state/category/provider/provider-surface/materializer/transport/connect-cluster/connector-class/source-provider/connector/worker/current-node/teardown-current-node/mutation-current-node/operation drill-down filters, or broader external or edge-aware CDC hardening beyond the shipped external report-id and freshness hardening, reporter-lease and edge-node provenance, multi-reporter reconciliation, stable takeover/degraded semantics, reporter rejoin plus stale-conflict cleanup, reporter/edge/coordination/degraded drill-down operator surfaces, declared-versus-reported runtime coverage hardening, runtime-level remediation summaries, managed-connector governance posture plus drill-down filters, managed-connector desired-versus-observed drift posture plus drill-down filters, managed-connector action-planning posture plus action drill-down filters, managed-connector write-path readiness posture plus readiness drill-down filters, managed-connector preflight posture plus preflight drill-down filters, managed-connector dry-run posture plus dry-run drill-down filters, managed-connector execution-intent posture plus execution-intent drill-down filters, managed-connector execution-approval posture plus execution-approval drill-down filters, managed-connector command-envelope posture plus command-envelope drill-down filters, managed-connector command-issuance posture plus command-issuance drill-down filters, managed-connector command-retry posture plus command-retry drill-down filters, managed-connector retry-execution-policy posture plus retry-execution-policy drill-down filters, managed-connector bounded command-journal posture plus journal drill-down filters, managed-connector automatic background retry posture plus automatic-retry drill-down filters, managed-connector automatic background retry coordination posture plus coordination drill-down filters, managed-connector durable command-journal posture plus durability drill-down filters, managed-connector distributed retry lease posture plus lease drill-down filters, MongoDB change streams, SQL Server CDC, PostgreSQL logical replication, MySQL binlog lifecycle/resume hardening, Oracle LogMiner lifecycle/resume hardening, the Debezium managed-connector baseline, the Debezium lifecycle and reconciliation hardening baseline, the richer execution-runtime operator-rollup baseline, and shared provider-native plus external execution/runtime-story baselines

  • additional provider-specific capture implementations plus provider-specific hardening beyond the shipped shared ICdcCapture, ICdcCaptureAcknowledger, ICdcCaptureExecutionRuntimeCatalog, configuration-declared external-runtime baseline, typed outbox-linked descriptor/runtime-state/freshness/lag/publication baseline, the shipped MongoDB change-stream runner, the shipped SQL Server CDC runner, the shipped PostgreSQL logical-replication runner, the shipped PostgreSQL publication/slot lifecycle plus restart-resume hardening baseline, the shipped MySQL binlog runner, the shipped MySQL lifecycle/resume hardening baseline, the shipped Oracle LogMiner runner, the shipped Oracle lifecycle/resume hardening baseline, the shipped Debezium managed-connector baseline, the shipped Debezium lifecycle and reconciliation hardening baseline, the shipped report-id/out-of-order/freshness-expiry hardening baseline, the shipped reporter-lease and edge-aware topology hardening baseline, the shipped reporter failover/takeover coordination baseline, the shipped richer multi-reporter reconciliation/operator-story hardening baseline, the shipped stronger reporter takeover/degraded-posture hardening baseline, the shipped reporter rejoin plus stale-conflict cleanup baseline, the shipped reporter/edge/coordination/degraded drill-down baseline, the shipped declared-versus-reported runtime coverage baseline, the shipped runtime-level remediation baseline, the shipped managed-connector governance baseline, the shipped managed-connector drift baseline, the shipped managed-connector action-planning baseline, the shipped managed-connector execution outcome/history baseline, the shipped managed-connector retry/idempotency hardening baseline, the shipped managed-connector retry-execution-policy baseline, the shipped managed-connector bounded command-journal baseline, the shipped managed-connector automatic background retry baseline, and the shared execution/runtime-story surfaces

Exit criteria:

  • modules can declare cell boundaries, governed cell routes, and cell health-isolation posture with explicit blast-radius isolation, project-level configuration can overlay deterministic automation policy through Engine:Cells:TrafficAutomation, including additive providerId plus edgeNodeIds targeting, provider-managed or edge-managed routes can publish selected materializer ownership plus the latest startup or live observation posture through providerMaterializerId, providerMaterializationState, providerMaterializationObservedAtUtc, providerMaterializationError, edgeMaterializerId, edgeMaterializationState, edgeMaterializationObservedAtUtc, edgeMaterializationError, the derived overall materializationState, materializationObservedAtUtc, and materializationError, and the shared lifecycle vocabulary on providerMaterialization.*, edgeMaterialization.*, and materialization.* metadata for ownership, dependency, drift, lifecycle action, additive cleanup-sweep posture, cleanup strategy, and primary/dependency cleanup breakdowns, provider-specific control-plane follow-through can now publish deterministic Kubernetes Gateway API projected intent, opt-in live Gateway/HTTPRoute observation, owned HTTPRoute apply-and-reconcile, and opt-in cleanup-sweep posture through Cephalon.Edge.KubernetesGateway plus the kubernetes-gateway-traffic-materializations technology surface, plus deterministic Traefik IngressRoute projected intent, opt-in live observation, owned IngressRoute apply-and-reconcile, and opt-in cleanup-sweep posture through Cephalon.Edge.Traefik plus the traefik-ingressroute-traffic-materializations technology surface, and operators can inspect the same answers through /engine/cells, /engine/cell-routes, /engine/cell-health-isolations, /engine/cell-traffic-automations, /engine/cell-traffic-automations/providers/{providerId}, /engine/cell-traffic-automations/edge-nodes/{edgeNodeId}, /engine/technology-surfaces/cell-based-architecture, and /engine/snapshot
  • modules can expose queryable data products through the runtime catalog
  • modules can declare CDC captures linked to an outbox through the runtime catalog today, operators can inspect descriptor truth, per-capture runtime posture, capture-side authored/requested/effective execution ownership, shared/configured/provider-native/external-managed execution-topology ownership, out-of-process live reporting, stable report ids, configured stale-window freshness expiry, optional out-of-order rejection, reporter identities, reporter-lease enforcement, reporter failover/takeover coordination posture, stable takeover-state plus degraded-reason answers, declared edge-node allow-lists, reporter/edge runtime summaries, linked runtime summaries, additive execution-runtime coordination rollups, runtime-level declared-versus-reported coverage, runtime-level remediation posture, managed-connector governance posture, managed-connector desired-versus-observed drift posture, managed-connector action-planning posture, managed-connector write-path readiness posture, managed-connector preflight posture, managed-connector dry-run posture, managed-connector execution-intent posture, managed-connector execution-approval posture, managed-connector command-envelope posture, managed-connector command-issuance posture, managed-connector execution-adapter posture, managed-connector command-execution posture, managed-connector retry/idempotency posture, and runtime-first remediation, governance, drift, action-plan-state, action-id, readiness-state, readiness-category, preflight-state, preflight-category, preflight-operation, dry-run-state, dry-run-category, dry-run-operation, execution-intent-state, execution-intent-category, execution-intent-operation, execution-approval-state, execution-approval-category, execution-approval-operation, command-envelope-state, command-envelope-category, command-envelope-operation, command-issuance-state, command-issuance-category, command-issuance-operation, execution-adapter-state, execution-adapter-category, execution-adapter-operation, command-execution-state, command-execution-operation, command-retry-state, command-retry-category, or command-retry-operation drill-downs through /engine/cdc-captures, /engine/cdc-captures/runtime, /engine/cdc-capture-runtimes, /engine/cdc-captures/execution-runtimes/{executionRuntimeId}, /engine/cdc-captures/runtime/execution-runtimes/{executionRuntimeId}, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, /engine/cdc-capture-runtimes/remediation/{remediationState}, /engine/cdc-capture-runtimes/remediation/categories/{remediationCategory}, /engine/cdc-capture-runtimes/governance/{governanceState}, /engine/cdc-capture-runtimes/governance/categories/{governanceCategory}, /engine/cdc-capture-runtimes/drift/{driftState}, /engine/cdc-capture-runtimes/drift/categories/{driftCategory}, /engine/cdc-capture-runtimes/action-plans/{actionPlanState}, /engine/cdc-capture-runtimes/actions/{actionId}, /engine/cdc-capture-runtimes/write-path-readiness/{readinessState}, /engine/cdc-capture-runtimes/write-path-readiness/categories/{readinessCategory}, /engine/cdc-capture-runtimes/preflight/{preflightState}, /engine/cdc-capture-runtimes/preflight/categories/{preflightCategory}, /engine/cdc-capture-runtimes/preflight/operations/{operationId}, /engine/cdc-capture-runtimes/dry-runs/{dryRunState}, /engine/cdc-capture-runtimes/dry-runs/categories/{dryRunCategory}, /engine/cdc-capture-runtimes/dry-runs/operations/{operationId}, /engine/cdc-capture-runtimes/execution-intents/{executionIntentState}, /engine/cdc-capture-runtimes/execution-intents/categories/{executionIntentCategory}, /engine/cdc-capture-runtimes/execution-intents/operations/{operationId}, /engine/cdc-capture-runtimes/execution-approvals/{executionApprovalState}, /engine/cdc-capture-runtimes/execution-approvals/categories/{executionApprovalCategory}, /engine/cdc-capture-runtimes/execution-approvals/operations/{operationId}, /engine/cdc-capture-runtimes/command-envelopes/{commandState}, /engine/cdc-capture-runtimes/command-envelopes/categories/{commandCategory}, /engine/cdc-capture-runtimes/command-envelopes/operations/{operationId}, /engine/cdc-capture-runtimes/command-issuances/{issuanceState}, /engine/cdc-capture-runtimes/command-issuances/categories/{issuanceCategory}, /engine/cdc-capture-runtimes/command-issuances/operations/{operationId}, /engine/cdc-capture-runtimes/execution-adapters/{executionAdapterState}, /engine/cdc-capture-runtimes/execution-adapters/categories/{executionAdapterCategory}, /engine/cdc-capture-runtimes/execution-adapters/operations/{operationId}, /engine/cdc-capture-runtimes/command-executions/{executionState}, /engine/cdc-capture-runtimes/command-executions/operations/{operationId}, /engine/cdc-capture-runtimes/{executionRuntimeId}/command-executions, /engine/cdc-capture-runtimes/command-retries/{retryState}, /engine/cdc-capture-runtimes/command-retries/categories/{retryCategory}, /engine/cdc-capture-runtimes/command-retries/operations/{operationId}, POST /engine/cdc-capture-runtimes/{executionRuntimeId}/commands/{operationId}, and /engine/snapshot, hosts can optionally run the shared in-process CDC pump with post-stage provider acknowledgement through /engine/execution-graphs, /engine/hosted-executions, and /engine/runtime-story, the shipped MongoDB change-stream runner plus the shipped SQL Server CDC runner plus the shipped PostgreSQL logical-replication runner plus the shipped MySQL binlog runner plus the shipped Oracle LogMiner runner plus the shipped Debezium managed-connector baseline now prove that additive model across document, relational change-table, relational logical-streaming, relational binlog, relational redo-log, and external managed-connector sources, and later additional provider-specific implementations or alternate execution topologies can build on the same registry instead of inventing a second one
  • keep host-specific APIs out of Cephalon.Abstractions
  • keep blueprint, transport, and policy selection configuration-driven by default
  • keep scaffolding, CLI, and package catalogs aligned with runtime contracts
  • prefer benchmark coverage before optimizing or refactoring hot paths blindly
  • do not start distributed orchestration before package loading and runtime policy are stable
  • prefer one shipped companion proof per infrastructure category until the runtime-neutral contract is proven; for phase 8 messaging that proof is currently Wolverine, but it remains optional for consumer apps
  • keep MassTransit in the tracked-later candidate set until the runtime-neutral eventing contract and the current Wolverine proof are strong enough to justify a second shipped companion adapter
  • allow consumer-owned infrastructure choices such as MediatR, LiteBus, NServiceBus, and SlimMessageBus, but do not claim first-class runtime truth for them without an explicit Cephalon bridge or adapter
  • keep one durable-messaging owner per flow; do not mix Cephalon-managed and third-party durable messaging semantics on the same path