Cephalon Project Memory

Project memory in this document reflects the repository state observed on May 2, 2026.

This page is a repo-oriented orientation snapshot. It is meant to help contributors recover context quickly before they change code, docs, planning, or package surfaces.

Cross-references: README.md, docs/README.md, docs/architecture.md, docs/architecture-inventory.md, docs/architecture-recommendations.md, docs/engine-roadmap.md, docs/engine-backlog.md, docs/compatibility.md, docs/long-range-direction.md, docs/engineering-standards.md, docs/dotnet11-readiness.md, docs/runtime-contract-index.md, docs/conformance-matrix.md, docs/architecture-review-2026-04.md, docs/architecture-review-2026-05.md, docs/planning-governance.md, docs/deployment-mode-support.md

Identity

Cephalon is not being positioned as a single application shell.

The repository is aiming at a modular .NET engine/framework foundation that is growing into a modular runtime platform. The recurring design center is:

host-agnostic contracts first
deterministic module and package composition
explicit app-model, transport, technology, and policy selection
runtime introspection as a product surface
additive companion packs instead of engine-core sprawl
generated starter output, templates, and samples that stay aligned with the runtime contract

Current technical baseline

the repo is pinned to .NET SDK 10.0.201 through global.json
the shipped project baseline is net10.0
notable packaging exceptions are the template pack and source generator surfaces that stay on netstandard2.0
repo-native framework assessment now lives in scripts/validate-dotnet-readiness.ps1, which keeps global.json-selected shipping truth separate from higher-SDK readiness checks
central package management is enabled through Directory.Packages.props
repo-wide build defaults enable nullable reference types, implicit usings, XML doc generation, and warnings-as-errors
the default Cephalon package version baseline is currently 0.1.0-preview

Long-term engine direction

the active north star is to build the best engine we can across architecture, runtime, tooling, packaging, documentation, and operational quality so developers can install Cephalon into many project shapes instead of adapting to one fixed app shell
Cephalon should continue evolving as a reusable engine/framework that developers install into many project shapes, not as a single opinionated app shell
current shipping should stay on net10.0, but official planning should assume Microsoft’s annual November .NET cadence, .NET 10 LTS support through November 14, 2028, and .NET 11 as the next major release currently in Preview 3 on April 26, 2026 with final release expected in November 2026
future-proofing should prefer a deliberate .NET 11 readiness lane over premature preview-only adoption: keep net10.0 as the stable shipping floor while reviewing new platform features, APIs, analyzers, and runtime behaviors early enough that Cephalon can migrate intentionally instead of reactively
release validation should continue emitting a framework-readiness report, while higher-SDK workflow lanes should validate future compatibility without mutating the repo-root global.json pin or silently changing the public baseline
treat the currently observed .NET 11 preview wave as assessment-only input for framework planning, not as a stable dependency baseline; as of April 26, 2026, Microsoft has shipped Preview 1 on February 10, 2026, Preview 2 on March 10, 2026, and Preview 3 on April 14, 2026, while stable Cephalon packages should continue targeting net10.0 until an intentional migration lane is validated
optimize for 3/5/8/10/15/20/30+ year adaptability by keeping the core host-agnostic, runtime truth introspectable, package boundaries explicit, and future workloads additive through companion packs instead of baking one architectural era directly into the engine
long-range planning should actively forecast how software may evolve over the next 3/5/8/10/15/20/30+ years and turn that forecast into engine primitives, package boundaries, runtime contracts, and migration lanes rather than waiting for external trends to force reactive redesign
assume the next decades of software will keep pushing toward AI-assisted authoring, lower-ceremony application assembly, stronger policy/governance requirements, hybrid cloud plus edge execution, and deploy-anywhere constraints such as trimming, single-file, containers, and Native AOT; Cephalon should answer those shifts through additive runtime primitives, generated/projected surfaces, and introspectable policy contracts instead of one locked-in application style
reduce consumer code aggressively: architecture, transport, host, and policy changes should prefer engine configuration, module composition, scaffold/runtime contracts, and generated low-code surfaces over app-local rewrites
consumer projects should be able to change architecture, transport mix, topology, and other major runtime choices through engine-owned composition, configuration, and projected surfaces without having to rewrite their application code each time
engine completeness should be measured by engine-owned, runtime-neutral contracts and swappable companion seams being ready, not by requiring one specific adapter or provider package to be installed
companion and provider packs such as Cephalon.Eventing.Wolverine are optional adoption choices for consumer apps; they may prove one managed implementation lane, but they must not redefine whether the core engine is considered ready
NuGet publication should stay discoverable and layered: keep a coherent package family around abstractions, engine core, host adapters, technology packs, provider packs, observability packs, tooling, scaffolding, templates, and samples/reference modules without collapsing everything into one monolith
NuGet publication is part of the product design, not release afterthought: package naming, taxonomy, split count, metadata, and search discoverability should be designed deliberately for framework adoption and long-term upgrade safety
NuGet publication should follow official library/package guidance: reserve and protect the Cephalon.* prefix when eligible, split packages only when the assemblies are independently useful, keep package metadata/README/tags/repository information complete, ship Source Link plus symbols, and use trusted publishing instead of long-lived manual secrets when the release flow is formalized
public API design should follow Microsoft library and framework guidance for reusable .NET libraries: keep constructors lightweight, prefer constructor injection and stable Add{Group} registration entry points, keep naming consistent, document public contracts with XML comments, and use the least-cost extensibility mechanism that preserves future evolution
compatibility discipline should stay high because Cephalon is a framework, not an app: avoid binary breaking changes in low-level packages unless the long-term design gain is worth a deliberate break, prefer additive opt-in settings and obsoletion over silent contract churn, and treat package dependencies as part of the public contract
framework-quality gates should keep expanding beyond unit tests: use analyzers and .editorconfig as policy, keep package validation baselines for public surface drift, keep NuGet vulnerability/supply-chain checks visible, and add truthful trimming/AOT/single-file readiness analysis where Cephalon claims those deployment modes
while the engine remains in POC, prefer materially better architecture, design patterns, packaging, code quality, developer ergonomics, or newly invented engine primitives over preserving transitional shapes that would weaken the long-term framework
treat performance, security, usability, reliability, maintainability, scalability, flexibility, compatibility, data integrity, availability, auditability, and compliance as first-class engine qualities rather than later hardening chores

Repo shape at a glance

Current project counts from the workspace scan:

src: 84 projects
tests: 4 projects
samples: 9 projects
templates: 6 projects
playground: 2 projects
benchmarks: 1 project

These counts are useful as a scale indicator only. They will drift as new companion packs and samples are added.

What the repository already ships

The repo is well past an early prototype. The following surfaces are already present and should be treated as part of the living product:

Cephalon.Abstractions as the host-agnostic contract layer
Cephalon.Engine as the composition, manifest, runtime, policy, package-loading, trust, and app-model center
Cephalon.AspNetCore and Cephalon.Worker as the primary host adapters
transport adapters for REST, JSON-RPC, gRPC, GraphQL, Server-Sent Events, and WebSocket
Cephalon.Scaffolding, Cephalon.Cli, and Cephalon.TemplatePack as the adoption and generation surfaces
Cephalon.ReferenceDocs plus the published docs/reference/ output as the XML-doc publishing path
Cephalon.Observability plus dependency-health, exporter, cloud, and provider companion packs
Cephalon.Behaviors plus HTTP, messaging, pattern, and source-generator companion packages
Cephalon.Data and Cephalon.EventSourcing plus relational and non-relational provider families
samples that model intended blueprint shapes and reference modules that model intended package authoring
the first deployment-mode validation harness ships through scripts/validate-deployment-mode-claims.ps1 (now manifest-driven through Get-DeploymentModeConfigFromManifest, reading per-mode requiredProjectProperties, requiredAnalyzerProperties, and warningPatterns from scripts/deployment-mode-support.json schema 1.1.0 with hardcoded fallback for legacy manifests) (3 audit phases: project-property, analyzer, optional dotnet publish probe; 5 verdict types: claim-truthful / claim-overstated / not-claimed / not-claimed-with-property-drift / mixed) plus a Pester suite at tests/Cephalon.Tests.Scripts/validate-deployment-mode-claims.Tests.ps1 (13 Describe groups, 67 It cases) plus a separate manifest-schema test file at tests/Cephalon.Tests.Scripts/deployment-mode-support-manifest.Tests.ps1 (9 Describe groups, 25 It cases) and a manifest schema at scripts/deployment-mode-support.json schema 1.1.0 with per-mode requiredProjectProperties, requiredAnalyzerProperties, warningPatterns, plus representativePublishTargets, expectedPublishOutputShape, deploymentModeEligibility, and knownTransitiveHazards fields
scripts/validate-release.ps1 now invokes the deployment-mode validation harness as an opt-out step (-SkipDeploymentModeClaims); release validation reports both .NET 11 SDK readiness and deployment-mode claim truth in the same flow, with the harness running in audit-only mode until representativePublishTargets.projects is populated
docs/conformance-matrix.md ships as the consolidated per-package adoption-truth read across maturity, ownership, engine routes, snapshot keys, and catalog interfaces; docs/runtime-contract-index.md ships as the consolidated /engine/* route, snapshot.* key, and runtime catalog interface map; both are linked from docs/README.md Research references and from docs/project-memory.md cross-references
docs/architecture-review-2026-05.md ships as the May 2026 dated architecture review snapshot synthesizing ENG-238 through ENG-256 plus phase-13 cell baseline and the new long-range / standards / runtime-contract / conformance-matrix anchors; the monthly cadence is now an explicit standing rule in docs/planning-governance.md

Runtime and architecture anchors

The architecture docs and the codebase align around a few important truths:

blueprints are not the same thing as design patterns, deployment topology, or transports
Cephalon models app shape through multiple dimensions rather than one overloaded architecture label
the built-in app blueprints are modular-monolith, modular-vertical-slice, and microservice
the built-in suite blueprint is microservice-suite
transports are first-class descriptors and are expected to stay aligned across runtime, scaffolding, CLI parsing, templates, samples, and docs
technology profiles are additive workload hints, not excuses to explode the blueprint catalog
the engine owns the runtime contract and generator surfaces should follow it instead of re-encoding their own semantics

Current built-in transport surface:

rest-api
json-rpc
grpc
graphql
server-sent-events
websocket

Current built-in technology profile surface includes:

agentic-workloads
cell-based-architecture
event-driven-integration
knowledge-retrieval
realtime-experience
edge-native-delivery
serverless-hosting
identity-access
multi-tenancy
hybrid-cloud-runtime
service-mesh-integration

High-value code anchors

When recovering context in code, these are good starting points:

src/Cephalon.Abstractions/Modules/IModule.cs
src/Cephalon.Abstractions/Modules/ModuleDescriptor.cs
src/Cephalon.Engine/Composition/EngineServiceCollectionExtensions.cs
src/Cephalon.Engine/Runtime/IRuntime.cs
src/Cephalon.Engine/Runtime/RuntimeOperationalStory.cs
src/Cephalon.AspNetCore/Hosting/EngineWebApplicationBuilderExtensions.cs
src/Cephalon.AspNetCore/Hosting/EngineWebApplicationExtensions.cs
src/Cephalon.Worker/Hosting/WorkerHostApplicationBuilderExtensions.cs
src/Cephalon.Cli/CliApplication.cs
src/Cephalon.Behaviors/Services/BehaviorDispatcher.cs
src/Cephalon.Abstractions/Behaviors/IBehaviorContext.cs

These files anchor the public or cross-cutting runtime contract more reliably than any one sample or playground host.

Introspection is part of the product

Runtime introspection is not secondary documentation. It is an explicit operator-facing surface.

Important routes and concepts that repeatedly appear across docs and code:

/engine
/engine/manifest
/engine/snapshot
/engine/runtime-story
/engine/cells
/engine/cell-routes
/engine/modules
/engine/packages
/engine/diagnostics
/engine/technologies
/engine/technology-catalog
/engine/technology-surfaces
/engine/capabilities
/engine/dependencies
/health
/health/live
/health/ready

If a change impacts lifecycle, packages, diagnostics, technologies, executions, or health semantics, it likely also impacts one or more of these routes and the docs that describe them.

Adoption surfaces

The repository now treats adoption as a first-class concern, not as a later packaging task.

The main adoption paths are:

Cephalon.Cli as a packaged .NET tool with the cephalon command
Cephalon.TemplatePack as the dotnet new install surface
Cephalon.Scaffolding as the shared rendering layer behind generated output
samples/ as adoption-quality blueprint examples
playground/ as freeform experimentation rather than the official starter baseline

The shipped template-pack module starters now include:

cephalon-module for host-agnostic modules
cephalon-rest-module for generic REST modules that do not dispatch into Cephalon behaviors
cephalon-rest-behavior-module for the recommended behavior-backed RestBehaviorModuleBase path
REST-enabled generated blueprint apps, dotnet new blueprint starters, and the matching shipped blueprint samples now also default their public starter modules to RestBehaviorModuleBase.ConfigureRestBehaviors(...) plus MapProfile<TBehavior>(); keep cephalon-rest-module and Cephalon.ReferenceModule.Operations as the generic non-behavior path instead of treating them as the starter baseline

The generated app baseline already includes publishing and deployment assets for:

published output smoke
Windows Service
IIS
Azure App Service
container image publishing
Azure Container Apps
Kubernetes
Linux systemd

Documentation model

The repository uses two documentation layers on purpose:

hand-authored Markdown under README.md and docs/ is the primary human-facing product and adoption documentation
XML comments on public contracts are the API explanation layer used by IntelliSense and generated reference-doc publishing

This distinction matters. Hand-authored docs should explain ownership, usage, architecture, and adoption. XML comments should explain supported public API behavior precisely enough for reference generation.

treat the hand-authored docs graph as the primary human contract and docs/reference/* as the generated API layer underneath it, not the other way around
before changing a package or subsystem, use docs/components/README.md as the map into the relevant component documentation before drilling directly into source
contributors should read the relevant docs/* material first and use broader software-world knowledge to shape the engine; the docs are new enough that they may and should evolve together with the code
when changing source, inspect the related docs graph every time; do not patch source and leave the nearby hand-authored docs drifting behind
if work touches a public surface, runtime surface, or package surface, review the source, component docs, compatibility docs, readiness/validation docs, and planning docs together as one change surface
if the current docs conflict with a better engine shape during the POC and invention phase, update docs + source + planning truth together in the same slice instead of preserving stale documentation just because it existed first

Planning memory

The roadmap and backlog indicate that Cephalon has already shipped large parts of its foundation, adoption hardening, operational baseline, package-loading baseline, execution/orchestration baseline, and solution-level platform baseline.

The near-term planning center has shifted away from “start the engine” and toward:

hardening and truthfulness across shipped surfaces
resilience and migration patterns
keeping docs, templates, CLI behavior, scaffolding, package metadata, and runtime contracts aligned
every meaningful package or runtime surface now needs an explicit maturity and ownership label through docs/engine-surface-maturity-audit.md: M0 through M4 plus taxonomy-only, application-managed, cephalon-managed, or provider-managed
intentional descriptor-only or catalog-only work is allowed, but it should stay explicitly labeled as M0 or M1 instead of reading like partial execution ownership
mixed-maturity families should prefer one narrow vertical proof slice before expanding descriptor breadth again
ENG-232 has now promoted Cephalon.Agentics from descriptor/runtime-surface truth into a narrow M2 proof: IAgentToolDispatcher owns one Cephalon-managed tool loop around registered IAgentToolExecutor services, IAgentToolExecutionPolicy can require approval or deny before execution, IAgentToolExecutionObserver can attach audit/telemetry, and IAgentToolRunCatalog projects run-state truth back into the agent-tools technology surface, /engine/agent-tool-runs, and snapshot.AgentToolRuns; this does not yet claim autonomous planning, memory persistence, retry queues, or AI-provider orchestration ownership
ENG-234 keeps Cephalon.MultiTenancy honest as a narrow M2 tenant-resolution proof: the base pack owns ITenantResolver, ITenantContextAccessor, and tenant-resolution, while tenant-governance-boundaries separates base-package ownership from companion-owned or companion-planned governance workflows
ENG-235 promotes the first governance companion proof: Cephalon.MultiTenancy.Governance owns tenant membership cataloging and membership evaluation through ITenantMembershipCatalog, ITenantMembershipEvaluator, tenancy.membership.catalog, tenancy.membership.evaluation, diagnostics 4510-4511, and the tenant-memberships runtime surface
ENG-236 promoted the second governance companion proof: Cephalon.MultiTenancy.Governance added tenant invitation cataloging and invitation validation through ITenantInvitationCatalog, ITenantInvitationValidator, tenancy.invitation.catalog, tenancy.invitation.validation, diagnostics 4512-4513, and the tenant-invitations runtime surface, while domain ownership, approval/remediation action decisions, durable membership or invitation stores, invitation delivery, identity-provider synchronization, and tenant administration remained future governance work after that slice; tenant administration workflow commands later shipped in ENG-254, the host-agnostic invitation delivery dispatch/run-state lane later shipped in ENG-256, and provider-specific senders plus identity-provider sync remain future work
ENG-237 promotes the third governance companion proof: Cephalon.MultiTenancy.Governance now also owns declared tenant-domain ownership cataloging and validation through ITenantDomainOwnershipCatalog, ITenantDomainOwnershipValidator, tenancy.domain-ownership.catalog, tenancy.domain-ownership.validation, diagnostics 4514-4515, and the tenant-domain-ownership runtime surface, while DNS/HTTP proof collection or external polling, approval/remediation action decisions, durable governance stores, invitation delivery, identity-provider synchronization, and tenant administration remained future governance work after that slice; action-state durability later shipped in ENG-240 and tenant administration workflow commands later shipped in ENG-254
ENG-238 promotes the fourth governance companion proof: Cephalon.MultiTenancy.Governance now also owns approval/remediation action cataloging and deterministic action decisions through ITenantGovernanceActionCatalog, ITenantGovernanceActionDecider, tenancy.governance-action.catalog, tenancy.governance-action.decision, diagnostics 4516-4517, and the tenant-governance-actions runtime surface
ENG-239 promotes the fifth governance companion proof: Cephalon.MultiTenancy.Governance now also owns in-process approval/remediation action workflow transitions through ITenantGovernanceActionWorkflow, TenantGovernanceActionWorkflowRequest, TenantGovernanceActionWorkflowResult, tenancy.governance-action.workflow, diagnostics 4518-4519, and runtime action metadata on the existing tenant-governance-actions surface
ENG-240 promotes the sixth governance companion proof: Cephalon.MultiTenancy.Governance now also owns runtime approval/remediation action storage through ITenantGovernanceActionStore, an in-memory default, opt-in file-backed JSON durability via GovernanceActionStoreFilePath, tenancy.governance-action.store, diagnostics 4520-4521, and action-store metadata on the existing tenant-governance-actions surface; durable membership storage was later narrowed and shipped in ENG-241, durable invitation storage was later narrowed and shipped in ENG-242, durable domain-ownership storage was later narrowed and shipped in ENG-243, tenant administration workflow commands later shipped in ENG-254, and the ASP.NET Core command endpoint later shipped in ENG-255, while distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, public onboarding, and tenant-admin UI remain future governance work
ENG-241 promotes the seventh governance companion proof: Cephalon.MultiTenancy.Governance now also owns runtime tenant-membership storage through ITenantMembershipStore, an in-memory default, opt-in file-backed JSON durability via MembershipStoreFilePath, tenancy.membership.store, and membership-store metadata on the existing tenant-memberships surface; durable invitation storage was later narrowed and shipped in ENG-242, durable domain-ownership storage was later narrowed and shipped in ENG-243, tenant administration workflow commands later shipped in ENG-254, and the ASP.NET Core command endpoint later shipped in ENG-255, while distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, public onboarding, and tenant-admin UI remain future governance work
ENG-242 promotes the eighth governance companion proof: Cephalon.MultiTenancy.Governance now also owns runtime tenant-invitation storage through ITenantInvitationStore, an in-memory default, opt-in file-backed JSON durability via InvitationStoreFilePath, tenancy.invitation.store, and invitation-store metadata on the existing tenant-invitations surface; durable domain-ownership storage was later narrowed and shipped in ENG-243, tenant administration workflow commands later shipped in ENG-254, and the ASP.NET Core command endpoint later shipped in ENG-255, while distributed or provider-backed governance storage, notification/delivery, invitation delivery, remediation execution beyond state transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, public onboarding, and tenant-admin UI remain future governance work
ENG-243 promotes the ninth governance companion proof: Cephalon.MultiTenancy.Governance now also owns runtime tenant-domain ownership storage through ITenantDomainOwnershipStore, an in-memory default, opt-in file-backed JSON durability via DomainOwnershipStoreFilePath, tenancy.domain-ownership.store, and domain-ownership-store metadata on the existing tenant-domain-ownership surface; in-process domain-ownership verification workflow transitions were later narrowed and shipped in ENG-244
ENG-244 promotes the tenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns in-process tenant-domain ownership verification workflow transitions through ITenantDomainOwnershipVerificationWorkflow, workflow request/result contracts, TenantDomainOwnershipVerificationWorkflowCommands, TenantDomainOwnershipVerificationWorkflowOutcomes, tenancy.domain-ownership.workflow, diagnostics 4522-4525, and tenant-domain-ownership metadata for verification-workflow ownership and DNS/HTTP proof-collection ownership boundaries, while DNS/HTTP proof collection or external polling, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, invitation delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, and tenant administration remained future governance work after that slice; tenant administration workflow commands later shipped in ENG-254
ENG-245 promotes the eleventh governance companion proof: Cephalon.MultiTenancy.Governance now also owns tenant-domain ownership proof evaluation through ITenantDomainOwnershipProofEvaluator, proof-evaluation request/result contracts, TenantDomainOwnershipProofEvaluationOutcomes, TenantDomainOwnershipProofMetadataKeys, tenancy.domain-ownership.proof-evaluation, diagnostics 4526-4527, and tenant-domain-ownership metadata for proof-evaluation ownership; HTTP file proof collection was later narrowed and shipped in ENG-248, configured DNS TXT proof collection was later narrowed and shipped in ENG-250, bounded on-demand proof polling was later narrowed and shipped in ENG-251, and automatic background proof polling was later narrowed and shipped in ENG-252
ENG-246 promotes the twelfth governance companion proof: Cephalon.MultiTenancy.Governance now also owns tenant-domain ownership proof challenge issuance through ITenantDomainOwnershipProofChallengeIssuer, proof-challenge request/result contracts, TenantDomainOwnershipProofChallengeOutcomes, TenantDomainOwnershipProofChallengeMetadataKeys, tenancy.domain-ownership.proof-challenge, diagnostics 4528-4529, default DNS TXT / HTTP publication hints, and tenant-domain-ownership metadata for proof-challenge ownership; HTTP file collection was later narrowed and shipped in ENG-248, configured DNS TXT collection was later narrowed and shipped in ENG-250, bounded on-demand proof polling was later narrowed and shipped in ENG-251, automatic background proof polling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253, while actual DNS proof publication remains future application/provider-managed work until a package owns that path explicitly
ENG-247 promotes the thirteenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns tenant-domain ownership proof publication planning through ITenantDomainOwnershipProofPublicationPlanner, proof-publication plan request/result contracts, TenantDomainOwnershipProofPublicationPlanOutcomes, TenantDomainOwnershipProofPublicationPlanMetadataKeys, tenancy.domain-ownership.proof-publication-plan, diagnostics 4530-4531, deterministic DNS TXT / HTTP file publication instructions, and tenant-domain-ownership metadata for proof-publication planning ownership; HTTP file proof collection was later narrowed and shipped in ENG-248, configured DNS TXT proof collection was later narrowed and shipped in ENG-250, bounded on-demand proof polling was later narrowed and shipped in ENG-251, automatic background proof polling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253, while actual DNS publication remains future application/provider-managed work until a package owns that path explicitly
ENG-248 promotes the fourteenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns on-demand tenant-domain ownership HTTP file proof collection through ITenantDomainOwnershipHttpProofCollector, HTTP proof-collection request/result contracts, TenantDomainOwnershipHttpProofCollectionOutcomes, TenantDomainOwnershipHttpProofCollectionMetadataKeys, tenancy.domain-ownership.http-proof-collection, diagnostics 4532-4533, HTTPS-by-default host-matched bounded HTTP file fetching, and tenant-domain-ownership metadata for HTTP proof-collection ownership while DNS publication, HTTP publication, provider mutation, and tenant-admin/public onboarding remained future application/provider-managed work at that slice boundary; configured DNS TXT proof collection was later narrowed and shipped in ENG-250, bounded on-demand proof polling was later narrowed and shipped in ENG-251, automatic background proof polling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253
ENG-249 promotes the fifteenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns tenant-domain ownership proof verification runner orchestration through ITenantDomainOwnershipProofVerificationRunner, proof-verification request/result contracts, TenantDomainOwnershipProofVerificationOutcomes, TenantDomainOwnershipProofVerificationMetadataKeys, tenancy.domain-ownership.proof-verification-runner, diagnostics 4534-4535, challenge/publication-plan/evaluation/optional HTTP collection orchestration, and tenant-domain-ownership metadata for proof-verification runner ownership while DNS publication, HTTP publication, provider mutation, and tenant-admin/public onboarding remained future application/provider-managed work at that slice boundary; configured DNS TXT proof collection was later narrowed and shipped in ENG-250, bounded on-demand proof polling was later narrowed and shipped in ENG-251, automatic background proof polling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253
ENG-250 promotes the sixteenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns configured on-demand tenant-domain ownership DNS TXT proof collection through ITenantDomainOwnershipDnsTxtProofCollector, DNS TXT proof-collection request/result contracts, TenantDomainOwnershipDnsTxtProofCollectionOutcomes, TenantDomainOwnershipDnsTxtProofCollectionMetadataKeys, tenancy.domain-ownership.dns-txt-proof-collection, diagnostics 4536-4537, explicit DNS-over-HTTPS resolver collection, normalized TXT answer evaluation, and tenant-domain-ownership metadata for configured DNS TXT proof-collection ownership while DNS publication, HTTP publication, provider mutation, and tenant-admin/public onboarding remained future application/provider-managed work at that slice boundary; bounded on-demand proof polling was later narrowed and shipped in ENG-251, automatic background proof polling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253
ENG-251 promotes the seventeenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns bounded on-demand tenant-domain ownership proof polling through ITenantDomainOwnershipProofPollingRunner, proof-polling request/result contracts, TenantDomainOwnershipProofPollingOutcomes, TenantDomainOwnershipProofPollingMetadataKeys, tenancy.domain-ownership.proof-polling-runner, diagnostics 4538-4539, catalog scans over pending/rejected HTTP file and DNS TXT declarations, verification-runner delegation, default batch limits, and tenant-domain-ownership metadata for proof-polling runner ownership plus externalProofPollingOwnership = cephalon-managed and backgroundProofPollingOwnership = application-managed, while DNS publication, HTTP publication, provider mutation, tenant-admin workflow, and public onboarding remained future application/provider-managed work at that slice boundary; automatic background scheduling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253
ENG-252 promotes the eighteenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns opt-in automatic background tenant-domain ownership proof polling through ITenantDomainOwnershipProofPollingRuntimeCatalog, TenantDomainOwnershipProofPollingRuntimeSnapshot, the TenantDomainOwnershipProofPollingHostedService, EnableDomainOwnershipProofBackgroundPolling, interval/startup/source options, tenancy.domain-ownership.proof-background-polling, diagnostics 4540-4543, runtime-surface metadata for interval, batch, last outcome, run counts, and ownership metadata that flips background proof polling to cephalon-managed only when enabled, while DNS publication, HTTP publication, provider mutation, tenant-admin workflow, and public onboarding remained future application/provider-managed work at that slice boundary; HTTP file proof publication was later narrowed and shipped in ENG-253
ENG-253 promotes the nineteenth governance companion proof: Cephalon.MultiTenancy.Governance now also owns tenant-domain ownership HTTP file proof publication through ITenantDomainOwnershipHttpProofPublisher, ITenantDomainOwnershipHttpProofPublicationCatalog, HTTP publication request/result/descriptor/outcome contracts, stable publication metadata keys, tenancy.domain-ownership.http-proof-publication, diagnostics 4544-4545, and tenant-domain-ownership metadata for HTTP proof-publication ownership/count; Cephalon.MultiTenancy.Governance.AspNetCore owns the opt-in ASP.NET Core endpoint adapter that serves published proof files while DNS publication, provider mutation, tenant-admin UI, and public onboarding remain future work until a package owns those paths explicitly
ENG-254 promotes the twentieth governance companion proof: Cephalon.MultiTenancy.Governance now also owns host-driven tenant administration workflow commands through ITenantAdministrationWorkflow, request/result/command/outcome/metadata-key contracts, membership grant/suspend/expire transitions, invitation issue/accept/revoke/expire transitions, store-failed persistence posture, tenancy.administration.workflow, diagnostics 4546-4547, the tenant-administration runtime surface, and base-package boundary truth while the ASP.NET Core command endpoint later shipped in ENG-255 and host-agnostic invitation delivery dispatch later shipped in ENG-256; tenant-admin UI, public onboarding, provider-specific invitation senders, and identity-provider synchronization remain future application/provider-managed work until a package owns those paths explicitly
ENG-255 promotes the first ASP.NET Core tenant-administration endpoint proof: Cephalon.MultiTenancy.Governance.AspNetCore now adds MapCephalonTenantAdministrationCommands(), the default POST /engine/tenant-administration/commands route, fail-closed authorization with optional policy configuration, TenantAdministrationWorkflowRequest to TenantAdministrationWorkflowResult command execution over ITenantAdministrationWorkflow, and the tenant-administration-http-endpoints runtime surface while the host-agnostic invitation delivery dispatch lane later shipped in ENG-256; tenant-admin UI, public onboarding, provider-specific invitation senders, identity-provider synchronization, distributed/provider-backed governance storage, and provider mutation remain outside this proof
ENG-256 promotes the twenty-first governance companion proof: Cephalon.MultiTenancy.Governance now owns host-agnostic tenant-invitation delivery dispatch through ITenantInvitationDeliveryDispatcher, ITenantInvitationDeliverySender, ITenantInvitationDeliveryRunCatalog, delivery request/result/run contracts, stable delivery metadata keys and outcomes, tenancy.invitation.delivery-dispatch, diagnostics 4548-4549, and tenant-invitations plus tenant-administration runtime metadata for dispatch enablement, sender IDs/count/ownership, external-delivery ownership, run history, and latest outcome; provider-specific email, SMS, chat, or identity-provider senders remain application/provider-managed until companion packages own those paths explicitly

Recent roadmap memory worth keeping in mind:

Sprint 35 shipped benchmark expansion for hot paths
Phase 11 is planned around resilience foundations such as circuit breaker, retry, timeout, bulkhead, rate limiting, and taxonomy additions such as Onion Architecture and Anti-Corruption Layer
Phase 12 is planned around migration and advanced coordination, including strangler fig, saga choreography, BFF, feature flags, and durable execution foundations; the descriptor-only taxonomy slice is now shipped through strangler-fig and backend-for-frontend, the first strangler-fig runtime-contract slice is now shipped through IStranglerFigRouteContributor, IStranglerFigRuntimeCatalog, IStranglerFigRouter, /engine/strangler-fig, and snapshot.StranglerFigRoutes, the first configuration-driven policy/progress slice is now also shipped through Engine:Migration:StranglerFig, IStranglerFigMigrationRuntimeCatalog, /engine/strangler-fig/runtime, and snapshot.StranglerFigRoutePolicies, the first ASP.NET Core host-level cutover slice is now shipped through Engine:Migration:StranglerFig:AspNetCore, /engine/strangler-fig/cutover, and /engine/strangler-fig/cutover/resolve, the first BFF client-binding runtime is now shipped through BackendForFrontendClientBindingDescriptor, IBackendForFrontendRuntimeCatalog, Engine:BackendForFrontend:Bindings, /engine/backend-for-frontend, and snapshot.BackendForFrontendBindings, the first client-aware BFF REST filtering runtime is now shipped through BackendForFrontendRestEndpointRuntimeDescriptor, IBackendForFrontendRestRuntimeCatalog, /engine/backend-for-frontend/rest-endpoints, and snapshot.BackendForFrontendRestEndpoints, the first BFF REST documentation/materialization runtime is now shipped through BackendForFrontendRestDocumentRuntimeDescriptor, IBackendForFrontendRestDocumentRuntimeCatalog, /engine/backend-for-frontend/rest-documents, filtered OpenAPI plus Scalar surfaces, and snapshot.BackendForFrontendRestDocuments, the first feature-flag runtime baseline is now shipped through FeatureFlagDescriptor, IFeatureToggle, IFeatureFlagRuntimeCatalog, Engine:Features, /engine/features, 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 host-agnostic saga choreography baseline is now also shipped through IBehaviorTopologyBuilder.AsSagaChoreography(), ISagaChoreographyPublisher, SagaChoreographyPublication, SagaChoreographyStepResult, InMemorySagaChoreographyPublisher, ChoreographySagaExecutionStrategy, capability behaviors.saga-choreography, and advisory ABT-005, the explicit saga choreography 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 saga choreography authoring-helper follow-through is now also shipped through ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, SagaChoreographyStepResult<TOutput>, and typed JSON helper factories on SagaChoreographyPublication, the first choreography runtime/operator catalog follow-through is now also shipped through SagaChoreographyRuntimeDescriptor, ISagaChoreographyRuntimeCatalog, /engine/saga-choreographies, and snapshot.SagaChoreographies, the first live choreography publication-state follow-through is now also shipped through SagaChoreographyPublicationRuntimeState, ISagaChoreographyPublicationRuntimeStateCatalog, /engine/saga-choreographies/runtime*, and snapshot.SagaChoreographyPublicationStates, the saga choreography capability-publication follow-through is now also shipped through behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state, and the first durable-execution baseline is now also shipped through IBehaviorTopologyBuilder.AsDurableExecution(), IDurableExecution<TState>, IDurableExecution<TInput, TState, TOutput>, DurableExecutionState<TState>, DurableExecutionStepResult<TOutput>, DurableExecutionStrategy, capability behaviors.durable-execution, compatibility rule ABT-006, and scoped IEventStore handoff through Kafka/RabbitMQ/test behavior contexts; the first durable runtime/operator follow-through is now also shipped through DurableExecutionRuntimeDescriptor, IDurableExecutionRuntimeCatalog, /engine/durable-executions, and snapshot.DurableExecutions, 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, the durable waiting runtime posture, /engine/durable-executions/runtime/timers*, and /engine/durable-executions/runtime/signals*, and the first durable compensation-helper follow-through is now also shipped through DurableExecutionCompensationAction, DurableExecutionStepResult<TOutput>.CompensationActions, DurableExecutionRuntimeState.CompensationActions, and /engine/durable-executions/runtime/compensations*, while broader traffic-manager or ingress follow-through, non-REST frontend materialization, and provider-specific feature-flag companion packs remain later work
the 2026-04-19 ENG-120 slice opened phase 13 with the first cell-based architecture boundary baseline: Cephalon.Abstractions now ships CellBoundaryDescriptor, ICellBoundaryContributor, ICellBoundaryRegistry, and ICellBoundaryCatalog, Cephalon.Engine now projects snapshot.CellBoundaries plus the cell-boundaries technology runtime surface, active cell boundaries now auto-select the built-in cell-based-architecture profile, and ASP.NET Core now exposes /engine/cells*
the 2026-04-19 ENG-121 slice extended that same phase-13 baseline with the first governed cell-route runtime: Cephalon.Abstractions now ships CellRouteDescriptor, ICellRouteContributor, ICellRouteRegistry, and ICellRouteCatalog, Cephalon.Engine now projects snapshot.CellRoutes plus the cell-routes technology runtime surface while validating route ownership against active cells, and ASP.NET Core now exposes /engine/cell-routes*
the 2026-04-19 ENG-122 slice extended that same phase-13 baseline again with the first cell health-isolation runtime: Cephalon.Abstractions now ships CellHealthIsolationDescriptor, ICellHealthIsolationContributor, ICellHealthIsolationRegistry, and ICellHealthIsolationCatalog, Cephalon.Engine now projects snapshot.CellHealthIsolations plus the cell-health-isolations technology runtime surface while validating isolation ownership against active cells, and ASP.NET Core now exposes /engine/cell-health-isolations* as the health posture drill-down over that shared cell graph
the 2026-04-20 ENG-123 slice completed the engine-owned phase-13 cell baseline with configuration-driven traffic automation: Cephalon.Abstractions now ships CellTrafficAutomationRuntimeDescriptor plus ICellTrafficAutomationRuntimeCatalog, Cephalon.Engine now binds Engine:Cells:TrafficAutomation into snapshot.CellTrafficAutomations plus the cell-traffic-automations technology runtime surface while deriving effective automation policy from active routes plus health isolations, and ASP.NET Core now exposes /engine/cell-traffic-automations*
the 2026-04-21 ENG-135 slice extended that same shared cell automation baseline with provider-aware and edge-aware targeting: CellTrafficAutomationRuntimeDescriptor now carries first-class ProviderId plus EdgeNodeIds, ICellTrafficAutomationRuntimeCatalog now answers provider and edge-node drill-downs, Engine:Cells:TrafficAutomation now supports additive provider plus edge defaults and route overrides, and ASP.NET Core now exposes /engine/cell-traffic-automations/providers/{providerId} plus /engine/cell-traffic-automations/edge-nodes/{edgeNodeId} while the same catalog still stays derived from routes plus health isolations
the 2026-04-21 ENG-136 slice added the first provider-managed cell traffic materializer baseline: Cephalon.Abstractions now ships ICellTrafficAutomationProviderMaterializer plus typed provider-materialization result/state contracts, Cephalon.Engine now selects provider materializers by providerId, seeds pending or unavailable answers onto the shared automation catalog, and runs startup reconciliation back into snapshot.CellTrafficAutomations, /engine/cell-traffic-automations*, and the cell-traffic-automations technology surface
the 2026-04-21 ENG-137 slice added the first edge-runtime cell traffic materializer baseline: Cephalon.Abstractions now ships CellTrafficAutomationMaterializationResult, CellTrafficAutomationMaterializationStates, and ICellTrafficAutomationEdgeMaterializer, Cephalon.Engine now selects one edge materializer per edge-managed or provider-and-edge-managed automation and writes the observed posture back into the same shared automation catalog, and Cephalon.Edge now contributes EdgeTrafficAutomationMaterializer so targeted edgeNodeIds reconcile through the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface
the 2026-04-21 ENG-138 slice hardened richer multi-provider reconciliation on that same shared cell automation baseline: ICellTrafficAutomationProviderMaterializer now carries Priority plus CanMaterialize(...), ICellTrafficAutomationEdgeMaterializer now carries Priority, CellTrafficAutomationRuntimeDescriptor now carries derived MaterializationState, MaterializationObservedAtUtc, and MaterializationError, and Cephalon.Engine now selects the highest-priority matching provider or edge materializer while publishing matching-candidate counts, selected-priority metadata, and overall state breakdown on /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and the cell-traffic-automations technology surface
the 2026-04-21 ENG-139 slice added the first provider-specific control-plane materializer through Cephalon.Edge.KubernetesGateway: KubernetesGatewayTrafficMaterializerOptions, KubernetesGatewayTrafficRouteOptions, and AddKubernetesGatewayTrafficMaterializer(...) now project deterministic Kubernetes Gateway API intent back onto the same shared automation catalog and the provider-facing kubernetes-gateway-traffic-materializations technology surface while keeping statusSource = configured-intent truthful
the 2026-04-21 ENG-140 slice added the first live Kubernetes Gateway observation overlay on that same baseline: Cephalon.Abstractions now ships ICellTrafficAutomationMaterializationReportSink, Cephalon.Engine now lets provider or edge observers merge live materialization answers back into the same shared automation catalog, and Cephalon.Edge.KubernetesGateway now adds KubernetesGatewayTrafficObservationModes, KubernetesGatewayTrafficObservationOptions, and opt-in observe-only polling so selected routes can publish live Gateway plus HTTPRoute conditions, drift, and freshness metadata through /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations
the 2026-04-21 ENG-141 slice hardened that same Kubernetes Gateway baseline with the first apply-and-reconcile loop: KubernetesGatewayTrafficObservationModes now adds apply-and-reconcile, configured intent now stays truthfully pending, Cephalon.Edge.KubernetesGateway now writes only owned HTTPRoute resources while treating Gateway as a pre-provisioned dependency, and the same shared automation surfaces now publish ownership-aware write metadata together with observed Gateway plus HTTPRoute status
the 2026-04-21 ENG-142 slice proved the shared provider-materializer seam against a second control-plane family through Cephalon.Edge.Traefik: TraefikTrafficMaterializerOptions, TraefikIngressRouteOptions, TraefikMiddlewareReferenceOptions, and AddTraefikTrafficMaterializer(...) now project deterministic Traefik IngressRoute intent back onto the same shared automation catalog and the provider-facing traefik-ingressroute-traffic-materializations technology surface while keeping statusSource = configured-intent truthful
the 2026-04-21 ENG-143 slice hardened shared control-plane ownership lifecycle truth on that same automation baseline: Cephalon.Abstractions now ships CellTrafficAutomationOwnershipStates, CellTrafficAutomationDependencyStates, CellTrafficAutomationDriftStates, and CellTrafficAutomationLifecycleActions, Cephalon.Engine now seeds and derives normalized providerMaterialization.*, edgeMaterialization.*, and materialization.* lifecycle summaries for ownership, dependency, drift, and lifecycle action on the same /engine/cell-traffic-automations* plus snapshot.CellTrafficAutomations surfaces, and Cephalon.Edge, Cephalon.Edge.KubernetesGateway, plus Cephalon.Edge.Traefik now publish the same lifecycle vocabulary instead of provider-local status taxonomies
the 2026-04-21 ENG-144 slice added the first live Traefik observation overlay on that same baseline: Cephalon.Edge.Traefik now ships TraefikTrafficObservationModes, TraefikTrafficObservationOptions, and opt-in observe-only polling over Traefik IngressRoute, Middleware, TLSOption, backend Service, and TLS Secret resources so selected routes can publish live existence, ownership, dependency, drift, and freshness metadata through /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations while keeping write ownership and apply-and-reconcile as later follow-through
the 2026-04-21 ENG-145 slice closed that immediate Traefik follow-through with the first owned apply-and-reconcile loop: TraefikTrafficObservationModes now adds apply-and-reconcile, 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 shared automation surfaces now publish statusSource = control-plane-apply, ingressRouteWriteAction, and merged live Traefik observation truth without inventing a second registry
the 2026-04-22 ENG-146 slice hardened 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
the 2026-04-22 ENG-147 slice closed the first provider-native cleanup sweep baseline 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 shared automation plus provider-specific surfaces now publish additive providerMaterialization.cleanup*, cleanupState, cleanupObservedAtUtc, and cleanup lifecycle summaries without inventing a second lifecycle registry
the 2026-04-22 ENG-150 slice added richer provider-native condition semantics on that same 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, and Cephalon.Engine, Cephalon.Edge, Cephalon.Edge.KubernetesGateway, plus Cephalon.Edge.Traefik now publish additive materialization.*, providerMaterialization.*, and edgeMaterialization.* condition summaries such as conditionCount, conditionBreakdown, and highestConditionSeverity instead of provider-local condition vocabularies
the 2026-04-20 ENG-124 slice opened the first data mesh runtime baseline: Cephalon.Abstractions now ships IDataProduct<T> plus DataProductDescriptor, IDataProductCatalog, IDataProductContributor, and IDataProductRegistry, Cephalon.Engine now projects snapshot.DataProducts, and ASP.NET Core now exposes /engine/data-products* so module-owned query surfaces stay grounded in sourceModuleId, domainId, contractId, and mode; provider-specific self-serve data infrastructure remained later follow-through from that baseline
the 2026-04-20 ENG-125 slice closed the first CDC capture runtime baseline: Cephalon.Abstractions now ships ICdcCapture plus CdcCaptureDescriptor, ICdcCaptureCatalog, ICdcCaptureContributor, and ICdcCaptureRegistry, Cephalon.Engine now projects snapshot.CdcCaptures while validating sourceModuleId plus outboxId against active runtime truth, and ASP.NET Core now exposes /engine/cdc-captures* so module-owned CDC posture stays grounded in provider, sourceId, outboxId, mode, eventFormat, and resourceIds; provider-specific WAL/change-stream execution remains later follow-through
the 2026-04-20 ENG-126 slice added the first live CDC runtime-state follow-through: Cephalon.Abstractions now ships CdcCaptureRuntimeState plus ICdcCaptureRuntimeStateCatalog, Cephalon.Data now reports descriptor-backed capture observations through ICdcCaptureRuntimeReporter, Cephalon.Engine now projects snapshot.CdcCaptureStates, and ASP.NET Core now exposes /engine/cdc-captures/runtime* so operators can inspect latest capture counts, checkpoints, errors, and optional linked OutboxDispatchState without inventing a host-only CDC monitor
the 2026-04-20 ENG-127 slice extended that same CDC runtime baseline with typed operational posture: Cephalon.Abstractions now ships CdcCaptureFreshnessStatus, CdcCaptureLagStatus, and CdcCapturePublicationStatus, Cephalon.Data now lets CdcCaptureExecutionReport carry freshness windows, lag posture, pending source-change counts, and pending publication counts, and the shared runtime-state catalog now keeps snapshot.CdcCaptureStates plus /engine/cdc-captures/runtime* truthful with conservative linked-dispatch publication overlays instead of metadata-only parsing
the 2026-04-20 ENG-128 slice closed the shared CDC hosted-execution substrate baseline: Cephalon.Abstractions now ships CdcCaptureExecutionResult plus stable ICdcCapture.CdcCaptureId and IOutbox.OutboxId identities, Cephalon.Data now owns the optional in-process CDC pump through DataRuntimeOptions.EnableCdcExecution, data.cdc.execution, data-cdc-capture-flow, and data-cdc-capture-pump, the shared pump now stages bounded capture batches through the linked outbox while reporting back into the same CDC runtime-state catalog, and the broader runtime now exposes the same execution lifecycle through /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot.OperationalStory without replacing /engine/cdc-captures*
the 2026-04-20 ENG-129 slice closed the shared CDC acknowledgement and checkpoint-commit follow-through: Cephalon.Abstractions now ships CdcCaptureExecutionAcknowledgement plus ICdcCaptureAcknowledger, Cephalon.Data now lets the shared pump acknowledge provider progress only after linked outbox staging succeeds, the shared runtime now reports acknowledgement and acknowledgerServiceType metadata on success plus failureKind = acknowledgement with pending checkpoint/change-id metadata on acknowledgement failure, and the data-cdc-capture-flow execution graph now includes the explicit acknowledge-cdc-progress step so /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and /engine/snapshot stay aligned with the actual replay-safe loop
the 2026-04-20 ENG-130 slice closed the first CDC execution-runtime catalog baseline: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeDescriptor, CdcCaptureExecutionRuntimeSummary, and ICdcCaptureExecutionRuntimeCatalog, Cephalon.Data now contributes the shared data-cdc-capture-pump execution runtime with ownership/topology/acknowledgement metadata plus a summary derived from the shared CDC runtime-state catalog, Cephalon.Engine now projects snapshot.CdcCaptureExecutionRuntimes, and Cephalon.AspNetCore now exposes /engine/cdc-capture-runtimes* so shared or future provider-native CDC runners can publish one truthful execution-topology answer without replacing /engine/cdc-captures* or /engine/cdc-captures/runtime*
the 2026-04-21 ENG-131 slice closed the first CDC execution-ownership binding baseline: Cephalon.Abstractions now ships CdcCaptureExecutionBindingDescriptor, CdcCaptureDescriptor plus CdcCaptureRuntimeState now carry ExecutionBinding, Cephalon.Data now resolves authored/requested/effective capture ownership deterministically from active runtime claims while rejecting ambiguous competing claims and keeping the shared pump scoped to its effective owner, and Cephalon.AspNetCore now exposes /engine/cdc-captures/execution-runtimes/{executionRuntimeId} plus /engine/cdc-captures/runtime/execution-runtimes/{executionRuntimeId} so capture-first and runtime-first ownership views stay on the same truth
the 2026-04-21 ENG-132 slice closed the first CDC external execution-runtime declaration baseline: Cephalon.Abstractions now promotes first-class execution runtime ownership/topology/execution-link fields plus inverse GetByExecutionRuntimeId(...) lookups on the shared CDC catalogs, Cephalon.Data now accepts DataRuntimeOptions.CdcExecutionRuntimes through CdcCaptureExecutionRuntimeOptions and ConfiguredCdcCaptureExecutionRuntimeContributor so hosts can declare external-managed or provider-native runtimes on the same operator surface, and the shared pump now stays scoped away from captures effectively owned by those configured runtimes while /engine/cdc-capture-runtimes*, inverse capture/runtime routes, and snapshot stay aligned on the same truth
the 2026-04-21 ENG-133 slice shipped the first concrete provider-native CDC runner through Cephalon.Data.MongoDB: MongoDbChangeStreamCaptureOptions now contribute provider-native MongoDB change-stream captures, the runtime now exposes capability data.cdc.mongodb plus mongodb-change-stream-capture-flow and mongodb-change-stream-capture-pump, durable resume-token checkpoints now live in the MongoDB provider path, and CDC descriptors can preserve authored sourceModuleId while surfacing contributorModuleId separately when the provider pack contributes on behalf of another module
the 2026-04-21 ENG-134 slice closed the first external CDC runtime live-reporting baseline: Cephalon.Abstractions now ships CdcCaptureRuntimeObservation plus ICdcCaptureExecutionRuntimeReportSink, Cephalon.Data now exposes opt-in DataRuntimeOptions.EnableExternalCdcRuntimeReporting so the shared runtime-state catalog can accept validated execution-runtime-owned reports keyed by executionRuntimeId, and ASP.NET Core now exposes POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports only when that sink is active so out-of-process runners can refresh /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot without inventing a second registry
the 2026-04-22 ENG-148 slice added the second provider-native CDC runner and first relational proof on that same shared CDC runtime story: Cephalon.Data.SqlServer now contributes AddSqlServerData(...), SqlServerCdcCaptureOptions, sqlserver-cdc-capture-flow, sqlserver-cdc-capture-pump, durable startLsn|seqval|operation checkpoints, and the same /engine/cdc-* truth model already used by MongoDB so document and relational capture providers now sit on one ownership/runtime-story contract
the 2026-04-22 ENG-149 slice hardened that external CDC reporting seam with first-class retry, ordering, and freshness-expiry truth: CdcCaptureRuntimeObservation now carries stable ReportId, declared execution runtimes can now set ObservationStaleAfterSeconds plus RejectOutOfOrderReports, CdcCaptureRuntimeState plus CdcCaptureExecutionRuntimeSummary now surface LastReportId and typed ObservationFreshness, and the same POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now stay truthful under retries, delayed deliveries, and stale external runners without inventing a second watchdog registry
the 2026-04-22 ENG-152 slice deepened that same external and edge-aware CDC execution story with first-class reporter and edge identity: CdcCaptureRuntimeObservation plus CdcCaptureExecutionReport now carry ReporterId plus EdgeNodeId, declared execution runtimes can now set ReporterLeaseSeconds, RejectConflictingReporterIds, and EdgeNodeIds, CdcCaptureRuntimeState plus CdcCaptureExecutionRuntimeSummary now surface LastReporterId, ActiveReporterId, ReporterLeaseExpiresAtUtc, ObservedEdgeNodeIds, and LastEdgeNodeId, and the same POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now stay truthful under reporter-lease conflicts and edge-node allow-list validation without inventing a second topology coordinator
the 2026-04-22 ENG-153 slice added the third provider-native CDC runner and the first logical-replication streaming proof on that same shared runtime story: Cephalon.Data.Postgres now contributes 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 /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing a PostgreSQL-specific CDC registry
the 2026-04-22 ENG-154 slice hardened 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
the 2026-04-22 ENG-155 slice added richer external and edge-aware CDC failover plus takeover truth on that same shared runtime story: CdcCaptureRuntimeState plus CdcCaptureExecutionRuntimeSummary now surface typed ReporterCoordination, Cephalon.Data now records rejected conflicting reporters plus accepted post-expiry takeovers on the shared runtime-state catalog, and the same POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now answer active-owner versus expired-lease versus conflicted reporter posture without inventing a second topology coordinator
the 2026-04-22 ENG-156 slice hardened that same shared external CDC runtime story with richer multi-reporter reconciliation and operator-story truth: 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 same POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces without inventing a second coordination registry
the next REST feature-rollout follow-through is now also shipped: ASP.NET Core endpoints can require one or more feature flags through RequireFeatureFlag(...) / RequireFeatureFlags(...), shorthand REST governance can rewrite or clear those rollout boundaries through RestApi:Overrides, request-time HTTP evaluation now feeds the active host environment into IFeatureToggle, and /engine/rest-endpoints plus snapshot.RestEndpoints preserve both effective and original required feature ids without hiding the published endpoint from operator introspection
the next shared behavior-execution feature-rollout follow-through is now also shipped: IBehaviorTopologyBuilder.RequireFeatureFlag(...) / RequireFeatureFlags(...), BehaviorTopologyDescriptor.RequiredFeatureFlagIds, and BehaviorTopologyDescriptor.SourceModuleId now let behavior authors keep rollout gates in the shared topology, source-generated literals preserve those ids, Cephalon.Behaviors evaluates them through IFeatureToggle using behavior/module/transport/environment/tenant/subject/tag context, BehaviorFeatureDisabledException keeps the rejection host-agnostic, BehaviorRuntimeContributor now reports feature-gated behavior counts plus per-behavior ownership metadata, and REST helper plus JSON-RPC transports now map the same shared gate without replacing it with host-only truth while messaging bindings treat disabled executions as skipped outcomes rather than retryable failures
the generic external-provider feature-flag bridge now keeps Cephalon descriptors as the runtime source of truth while letting provider packs contribute additional gates through typed bindings and IFeatureFlagProvider; /engine/features/{featureFlagId}/evaluate now publishes provider-result details, and behavior-owned HTTP execution now resolves subject identity from NameIdentifier, sub, or Identity.Name so provider-backed feature gates see the same subject truth as direct REST endpoint evaluation

Collaboration agreements

These are explicit working agreements from the current collaboration and should be extended as new standing decisions are made.

when the team settles on an approach, plan, recurring workflow, or repeated command pattern, record it in project memory so it does not rely on thread-local recall alone
when planning or docs start to imply that a package is runtime-ready, verify whether the surface is taxonomy-only, application-managed, cephalon-managed, or provider-managed before widening the claim
do not add descriptor-first breadth to mixed-maturity runtime packs unless the slice is intentionally labeled M0 or M1, or it carries a concrete proof path to M2 and beyond
when deeper or version-sensitive external research is needed, especially around .NET, .NET 10, libraries, frameworks, support policy, or official guidance, use internet research instead of relying only on prior model knowledge
when recording .NET planning decisions, prefer exact release and support dates over relative wording; the current official planning anchor is .NET 10 LTS released on November 11, 2025 with support through November 14, 2028, while .NET 11 is in Preview 3 on April 26, 2026 with final release expected in November 2026
when using preview-era .NET guidance for Cephalon planning, record the exact preview state and keep the decision boundary explicit: previews are for compatibility assessment, benchmarks, analyzer review, and migration rehearsal, while stable Cephalon packages stay on the current supported shipping floor until the migration lane is intentionally approved
when delegating research work to sub-agents, prefer primary and official sources first, then synthesize the result back into repo context for Cephalon-specific decisions
for meaningful work, prefer using sub-agents in complementary roles when that improves the outcome, for example business/product framing, architecture, design patterns, documentation, planning cards, quality review, testing, benchmarking, or other task-shaped specialties
sub-agents may be used freely when they materially improve the outcome; there is no artificial cap on how many architecture, documentation, quality, research, benchmarking, or planning helpers can collaborate on Cephalon work
let sub-agents collaborate as a working group rather than as isolated note takers; they can cross-check one another’s reasoning, surface tradeoffs, and help review the same change from different perspectives before the final decision lands
sub-agents may use internet research when it helps them validate framework guidance, technical options, benchmarks, security practices, documentation, or other external references that matter to the decision
repo-local memory is the reliable cross-thread source of truth; agreements that matter beyond the current thread should be written down here or in another repo-owned document
keep generic hosting tests deterministic by isolating them from transitive sample Configurations content, and keep sample-host tests such as the showcase harness pointing at their real project content roots explicitly instead of relying on whatever config files happen to be copied into a test output folder
Cephalon is still in an active POC and invention phase, so decisions should not stay trapped by the current implementation alone; if a materially better approach exists for engine quality, architecture, performance, security, developer ergonomics, or future-proofing, it is acceptable to change direction deliberately
when rethinking an area during this POC phase, optimize for making Cephalon a stronger long-term engine: reduce common developer pain, keep the platform broad enough for varied project types, and prefer durable engine primitives over short-term local convenience
Cephalon does not yet have legacy production consumers that must be preserved at all costs; when a compatibility shim conflicts with a cleaner long-term engine contract during the POC phase, prefer removing the shim and shipping the better design deliberately

Current standing examples from this collaboration:

keep important collaboration memory in docs/project-memory.md
keep the durable planning workflow explicit through docs/planning-governance.md; meaningful work must stay aligned across repo docs, GitHub Project tracking, sprint placement, validation expectations, and commit-reference history
once an ENG-* id is part of the durable project record, treat it as immutable; future planning resets should allocate fresh ids instead of reusing shipped history
treat internet-backed research as the default follow-through for sub-agent learning tasks when accuracy or freshness matters
when making reusable framework or package-family decisions, default to official Microsoft or NuGet guidance for library design, compatibility, analyzers, packaging, Source Link, and publishing hygiene before inventing a repo-local convention
package-family decisions should optimize for long-term discoverability and upgrade safety: prefer a coherent Cephalon.* taxonomy, complete NuGet metadata, Source Link, symbols, SemVer, package-validation baselines, and trusted publishing rather than treating packaging as an afterthought
future-facing Cephalon work should reduce end-user code by moving variability into engine-owned configuration, projected low-code surfaces, module/package composition, and runtime truth instead of requiring app projects to rewrite architecture decisions locally
when a coding task is complete and the change is validated, stage only the intended files, create a commit, keep master updated as the integration branch, push the finished work to GitHub, and leave project docs aligned with the shipped behavior
when a code change affects documented behavior, inspect the related docs/* graph and update every impacted hand-authored document that references that surface instead of patching only one nearby page
when work touches a public/runtime/package surface, check the live source together with docs/components/*, docs/compatibility.md, readiness or validation docs, and planning docs before deciding that the change is complete
when database-topology operator guidance becomes a stable reusable runtime answer, move it into an engine-owned route and snapshot contract first, then let the showcase sample consume that answer and add only sample-specific adaptation
GitHub Project cards should contain enough narrative detail for a reader to understand the work without extra thread context, and they should populate the standard fields Assignee, Label, Type, Project, Estimate, Iteration, Test, Benchmark, Milestone, and Relationship when cross-card references exist
when a commit materially advances a GitHub Project card, add a card comment that records what changed and references the commit id so the card keeps a readable implementation history
roadmap, backlog, sprint placement, plan details, and GitHub Project cards must stay synchronized; if scope, estimate, validation, milestone, or relationships change, update both the docs and the card instead of leaving one side stale
repository-facing written artifacts should be in English, including hand-authored documentation, commit messages, and planning or tracking content that becomes part of the project record
use sub-agents proactively for review, consultation, and parallel investigation when a task benefits from multiple perspectives instead of treating delegation as a last resort
default to the OpenAI Codex CLI (gpt-5.5) and Anthropic Claude Code (opus-4.7) as dual primary code-management seats for actively shaping, editing, refactoring, and committing repository source; either seat may drive any given slice while keeping the same docs + source + planning truth aligned through the existing docs/components/*, docs/project-memory.md, docs/architecture.md, docs/compatibility.md, docs/engine-roadmap.md, and docs/engine-backlog.md graph; other agents and tools may still research, review, validate, benchmark, or plan in parallel, but treat Codex CLI as the authoritative editing surface for landed code changes by default
when committing or pushing repository changes from any seat (Codex CLI, this assistant, or another tool), use the Cephalon-Neza Git/GitHub account as the default author and pusher so commit history, GitHub Project card comments, and remote push attribution stay aligned with the intended project identity instead of leaking ad-hoc local user identity into the durable record
when promoting trim, Native AOT, or single-file from not-claimed to claimed, the planned scripts/validate-deployment-mode-claims.ps1 harness’s claim-truthful verdict is the authoritative gate; analyzer-only signals, local publish experiments, or untruthful manifest edits do not widen the support contract by themselves (see docs/deployment-mode-support.md for harness scope)
keep future-facing engine quality in view during POC work, including architecture strength, design-pattern fit, performance, security, support for broad project shapes, and overall developer experience
when a host exposes both module-owned REST helpers and generic behavior HTTP routes, treat the module-owned REST groups as the public REST/OpenAPI/Scalar surface and keep the generic behavior routes focused on non-REST adapter transports
OpenApi:EnabledVersions and legacy OpenApi:Documents govern only the published OpenAPI + Scalar document set; generic behavior HTTP adapter routes resolve their version/document segment from ApiRoutes:DefaultBehaviorDocumentName or, when unset, the raw configured OpenApi:DefaultVersion
module-owned REST version segments default to the owning module major version; tests or harnesses that target a module-owned public REST surface should derive that /api/v{major} segment from module metadata instead of hardcoding v1, and showcase transport projections should keep restOperations separate from generic behavior transportIds
public REST is module-owned only: do not declare http.rest in [BehaviorAllowedTransports(...)] or ConfigureTopology(...); author REST through RestBehaviorModuleBase.ConfigureRestBehaviors(...) by default and reserve low-level MapBehaviorRestGroup(...) work for advanced/manual cases
lower-ceremony REST authoring is now shipped only as metadata or projection-driven shorthand that still materializes into module-owned public REST; do not go back to direct behavior-owned REST activation
if a higher-precedence module-owned REST mapping exists for a behavior, suppress lower-precedence implicit, generated, or convention REST projections for that same behavior by default instead of running them side by side
the shipped generated-module REST shorthand stays explicit and module-owned through IRestBehaviorEndpointGroupBuilder.MapGeneratedProfiles(), MapGeneratedProfiles(string), IRestBehaviorModuleBuilder.MapGeneratedProfileGroups(string), its shared-group-configuration overload, its derived-prefix-aware overload, and IRestBehaviorModuleBuilder.GroupFromBehaviorIdPrefix(string): it prefers source-generated GetRestProfiles() plus GetRestProfileBehaviorTypes() hints, falls back only to a bounded scan of the explicit owning module assembly when generated type hints are unavailable, can now derive /foo/bar from foo.bar for the common generated route-group path, can also fan one generated root prefix out into several derived route groups by each behavior id’s parent prefix while preserving the same generated shorthand/runtime truth, can now stamp different API-version/tag/governance-scope conventions per derived branch with awareness of the exact generated behavior-id prefix, and still never publishes public REST from [AppBehavior] alone
hosts can now govern that same shorthand ownership model by exact behavior id or subtree BehaviorIdPrefixes, which is especially important for MapGeneratedProfileGroups(...) because one rule can target one generated grouped branch without enumerating every exact generated candidate id
the shipped low-code inline module-owned REST helpers are engine.AddRestBehaviorModule<TMarker>(...), engine.AddGeneratedRestBehaviorModule<TMarker>(...), and engine.AddGeneratedRestBehaviorModuleGroups<TMarker>(...): their common moduleId / displayName / description overloads now keep the inline path terse without manual ModuleDescriptor construction, while the descriptor-based overloads remain the advanced path for richer inline metadata; all three forms materialize real modules without dedicated module classes, reuse the same normalized projection/materialization/candidate/publication-group/governance pipeline as RestBehaviorModuleBase, use TMarker as the source-assembly marker for generated profiles and as each helper’s distinct module-type identity, expect one stable marker type per inline module, let the common generated inline path derive its behavior-id prefix directly from the inline module id, let the grouped generated inline path keep the same MapGeneratedProfileGroups(...) ownership/runtime story without a dedicated module class, reuse the same fail-fast deterministic grouped-prefix validation across dedicated-module and inline-helper paths, keep explicit behaviorIdPrefix overloads available when inline module identity and generated ownership should differ, and still never publish public REST from [AppBehavior] alone
grouped generated shorthand can now also configure each derived group with awareness of its exact generated behavior-id prefix through both dedicated-module and inline-helper overloads, so one owner can stamp different API-version, tag, or host-governance-scope conventions per branch without leaving the low-code grouped-generated path; generated shorthand still remains host-governable by default
route groups can now also stamp one stable authored governance scope through WithHostGovernanceScope("scope"); that value flows into OriginalProjection.HostGovernanceScope for runtime truth and host selector targeting, but it does not opt explicit module-DSL routes into host governance by itself
scope-first REST governance validation should prefer real HostGovernanceScopes targeting over behavior-id stand-ins so suppression catalogs, override catalogs, publication groups, authoring-policy answers, and snapshot all prove the same selector story end to end
overlapping behavior-targeted REST governance rules now prefer exact behavior ids over broader subtree prefixes and then prefer longer prefixes over shorter ones; runtime selection-basis answers expose that decisive subtree reason as narrower-behavior-scope
even with the shipped low-code REST shorthand, [AppBehavior] plus auto-registration alone must still not publish a public REST boundary; shorthand must remain an explicit REST opt-in
the shipped behavior-authored REST metadata bridge is BehaviorRestProfileAttribute plus optional repeated BehaviorRestBindingAttribute declarations in Cephalon.Behaviors.Http: together they declare a candidate REST method, relative pattern, optional API major version, explicit route/query/header/body input-binding descriptors, and optional preserved implicit-query fallback intent for the shipped module-owned profile/generated projection paths, but they remain metadata-only, do not publish public REST by themselves, and do not override host OpenAPI document publication policy
the shipped explicit consumption path for that metadata is IRestBehaviorEndpointGroupBuilder.MapProfile<TBehavior>(): it stays module-owned, prefers source-generated GetRestProfiles() hints, falls back only to the explicitly targeted behavior type when generated hints are unavailable, seeds a group API version only when .ApiVersion(...) is not set explicitly, fails fast when profiled behaviors in the same group declare conflicting candidate API versions, preserves explicit binding descriptors through the same normalized projection pipeline, and now also honors profile-authored preserved implicit query fallback when the profile explicitly opts into it
the current RestBehaviorModuleBase DSL now compiles into a normalized internal REST projection contract before ASP.NET Core materialization, and the shipped runtime follow-through now exposes resolved public REST truth through IRestEndpointRuntimeCatalog, /engine/rest-endpoints, /engine/rest-endpoints/{restEndpointId}, and snapshot.RestEndpoints
the shipped profile-consumption shorthand keeps runtime publication on the same sourceKind = module-dsl path, while /engine/rest-endpoints now distinguishes shorthand-authored endpoints through first-class RestEndpointRuntimeDescriptor.AuthoringStyle = behavior-module-profile and exposes explicit profile-driven binding plans through the typed RestEndpointRuntimeDescriptor.BindingDescriptors surface plus the matching snapshot.RestEndpoints data instead of treating metadata dictionaries as the canonical answer
the shipped generated module-owned shorthand also keeps runtime publication on the same sourceKind = module-dsl path, while /engine/rest-endpoints now distinguishes generated shorthand through first-class RestEndpointRuntimeDescriptor.AuthoringStyle = behavior-module-generated
published behavior-backed endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.CandidateId, so operators can jump from /engine/rest-endpoints or snapshot.RestEndpoints directly to the originating shorthand candidate even when host overrides rewrote the final published route shape, while manual endpoints stay null
published endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.RouteGroupPrefix and RelativePattern, so operators can read the resolved grouped public route boundary directly from /engine/rest-endpoints or snapshot.RestEndpoints without treating metadata.routeGroupPrefix or metadata.relativePattern as the canonical runtime answer
published behavior-backed endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.BehaviorType, so operators can read the concrete behavior implementation identity directly from /engine/rest-endpoints or snapshot.RestEndpoints without treating metadata.behaviorType as the canonical runtime answer, while manual non-behavior endpoints stay null
published endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.SourceId, so operators can read the published source identity directly from /engine/rest-endpoints or snapshot.RestEndpoints without treating metadata.sourceId as the canonical runtime answer
published endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.OriginalRequiredCapabilityKey plus AppliedOverrideId, so the final /engine/rest-endpoints and snapshot.RestEndpoints surfaces can explain source-versus-effective capability governance directly when shorthand overrides rewrite or clear a public REST boundary
published endpoints now also expose ordered RestEndpointRuntimeDescriptor.MatchedOverrideIds, so operators can see the full shorthand override match set on the final published /engine/rest-endpoints and snapshot.RestEndpoints surface without joining back to the candidate catalog; capability-only no-op matches should stay visible there even when AppliedOverrideId remains null
the typed override-effect baseline now also exposes RestEndpointOverrideActionKind plus configured RestEndpointOverrideDescriptor.ActionKinds, while shorthand candidates and published endpoints now expose SelectedOverrideActionKinds plus AppliedOverrideActionKinds so declared-versus-effective override dimensions stay visible on /engine/rest-endpoint-overrides, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and the matching snapshot surfaces; no-op winners keep selected action kinds visible while applied action kinds remain empty
reorder-only shorthand binding overrides are now treated as semantic no-op governance everywhere the shipped shorthand pipeline compares binding plans: candidate resolution, projection reuse, and post-materialization structural override reconciliation all share the same equivalent-binding-set comparison, so if a host or future synthetic candidate path restates an equivalent explicit binding set in a different order, candidates and published endpoints keep MatchedOverrideIds visible but leave AppliedOverrideId = null, and the source explicit binding order remains the authoritative runtime answer
published endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.OriginalProjection, so operators can compare original shorthand method, route, document-version, tag, and binding-plan truth against the final published endpoint directly from /engine/rest-endpoints or snapshot.RestEndpoints without joining back to /engine/rest-endpoint-candidates; manual and behavior-helper endpoints stay null
published endpoints now also expose typed nullable RestEndpointRuntimeDescriptor.OriginalEndpointName, OriginalSummary, and OriginalDescription, so operators can compare original shorthand endpoint metadata against the final published endpoint directly from /engine/rest-endpoints or snapshot.RestEndpoints without falling back to behavior docs; manual and behavior-helper endpoints stay null
shorthand REST materialization now reads ProjectedEndpoint.RouteGroupPrefix directly when it publishes effective route groups, so compatibility metadata.routeGroupPrefix is no longer part of internal runtime behavior and the typed route-boundary contract now drives both operator introspection and actual ASP.NET Core route mapping
the shipped REST precedence-visibility baseline now also exposes IRestEndpointCandidateRuntimeCatalog, /engine/rest-endpoint-candidates, /engine/rest-endpoint-candidates/{candidateId}, and snapshot.RestEndpointCandidates, plus IRestEndpointPublicationGroupRuntimeCatalog, /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, and snapshot.RestEndpointPublicationGroups; within the normalized behavior-projection path the effective precedence is explicit module DSL > MapProfile<TBehavior>() > generated shorthand, where generated shorthand includes both MapGeneratedProfiles(...) and MapGeneratedProfileGroups(...), the candidate catalog now preserves both the original shorthand source shape through RestEndpointCandidateRuntimeDescriptor.OriginalProjection and the final effective mapped answer through ProjectedEndpoint, candidate ids now resolve from that original shorthand projection before host overrides are applied while ProjectedEndpoint.Id continues to identify the effective mapped endpoint shape, projected shorthand endpoints now also keep endpoint name plus summary/description metadata plus original shorthand endpoint name/summary/description lineage and host-governed required capability keys aligned with the final behavior-backed runtime endpoint conventions, and the grouped publication catalog now answers that same story per behavior through the published candidate ids, precedence-suppressed candidate ids, governance-suppressed candidate ids, winning precedence rank, and ordered candidate set
RestEndpointCandidateStatus now also carries stable published / suppressed wire names through RestEndpointCandidateStatusExtensions, so /engine/rest-endpoint-candidates, /engine/rest-endpoint-candidates/{candidateId}, and snapshot.RestEndpointCandidates expose readable operator-facing status truth instead of raw enum-number serialization
grouped publication answers now also expose RestEndpointPublicationGroupDescriptor.AuthoringStyleSummaries as typed RestEndpointPublicationGroupAuthoringStyleDescriptor entries derived directly from the same grouped candidate truth, so /engine/rest-endpoint-publication-groups and snapshot.RestEndpointPublicationGroups also show which shorthand authoring styles participated, which remained published, and which were precedence-suppressed or governance-suppressed without manually partitioning the ordered candidate set
grouped publication answers now also expose RestEndpointPublicationGroupDescriptor.AuthoringPolicy as typed RestEndpointPublicationGroupAuthoringPolicyDescriptor data, so /engine/rest-endpoint-publication-groups and snapshot.RestEndpointPublicationGroups distinguish the implicit default single-winner boundary from an explicit RestApi:AuthoringPolicies:{behaviorId} configuration; AllowMultiplePublishedCandidates is now an enforced field that can keep lower-precedence unsuppressed shorthand candidates published together when the final route answers stay distinct, and preferred/allowed/disallowed authoring-style fields now also enforce shorthand publication policy for behavior-module-profile and behavior-module-generated candidates through distinct authoring-policy suppression truth instead of reusing governance or precedence semantics
grouped publication answers now also expose typed RestEndpointPublicationGroupAuthoringPolicySuppressionDescriptor entries through AuthoringPolicySuppressionSummaries at both the behavior-group level and inside each AuthoringStyleSummaries entry, so /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, and snapshot.RestEndpointPublicationGroups keep the grouped disallowed-authoring-style, not-allowed-authoring-style, and preferred-authoring-style-selected authoring-policy breakdown visible without forcing operators to re-join candidate payloads
the shipped REST authoring-policy runtime baseline now also exposes IRestEndpointAuthoringPolicyRuntimeCatalog, /engine/rest-endpoint-authoring-policies, /engine/rest-endpoint-authoring-policies/{behaviorId}, and snapshot.RestEndpointAuthoringPolicies; that rule-centric behavior-level answer keeps explicit default-versus-configured policy intent, explicitly configured RestApi:AuthoringPolicies:{behaviorId} entries with no current candidates, and separate CandidateIds, RetainedCandidateIds, PublishedCandidateIds, PrecedenceSuppressedCandidateIds, GovernanceSuppressedCandidateIds, and grouped SuppressionSummaries visible without trapping authoring-policy truth only inside publication-group answers
that same rule-centric REST authoring-policy runtime answer now also exposes typed per-style RestEndpointAuthoringPolicyAuthoringStyleDescriptor entries through RestEndpointAuthoringPolicyDescriptor.AuthoringStyleSummaries, so /engine/rest-endpoint-authoring-policies and snapshot.RestEndpointAuthoringPolicies can partition candidate, retained, published, precedence-suppressed, governance-suppressed, and authoring-policy-suppressed outcomes by normalized authoring style while still keeping explicitly configured-but-unmatched policies visible with empty style summaries
that same rule-centric REST authoring-policy runtime answer now also keeps HostGovernanceEligibleCandidateIds, HostGovernanceIneligibleCandidateIds, SkippedSuppressionIds, and SkippedOverrideIds visible at both the behavior level and inside each RestEndpointAuthoringPolicyAuthoringStyleDescriptor, so explicit ownership that never entered host governance remains readable from /engine/rest-endpoint-authoring-policies and snapshot.RestEndpointAuthoringPolicies without reopening grouped publication answers
that same rule-centric REST authoring-policy runtime answer now also exposes grouped governance-rule summaries directly through GovernanceSuppressionSummaries, GovernanceOverrideSummaries, SkippedSuppressionSummaries, and SkippedOverrideSummaries at both the behavior level and inside each RestEndpointAuthoringPolicyAuthoringStyleDescriptor, using the generic RestEndpointGovernance*SummaryDescriptor contracts instead of publication-group-scoped types, so one authoring-policy payload can answer matched-versus-suppressed, selected-versus-applied, and skipped-rule candidate mappings without reopening grouped publication answers first
when REST policy or governance config can exist without active candidates, prefer a top-level rule or policy runtime catalog over burying that truth only inside grouped publication answers
grouped publication answers now also expose typed RestEndpointPublicationGroupGovernanceSuppressionSummaryDescriptor and RestEndpointPublicationGroupGovernanceOverrideSummaryDescriptor entries through GovernanceSuppressionSummaries and GovernanceOverrideSummaries at both the behavior-group level and inside each AuthoringStyleSummaries entry, so /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-publication-groups/{behaviorId}, and snapshot.RestEndpointPublicationGroups keep matched-versus-suppressed host suppression outcomes plus matched/selected/applied override outcomes visible, including no-op winning overrides whose applied bucket stays empty
grouped publication answers now also expose typed RestEndpointPublicationGroupGovernanceSelectionBasisSummaryDescriptor and RestEndpointPublicationGroupGovernanceOverrideActionKindSummaryDescriptor buckets through grouped suppression SelectionBasisSummaries plus grouped override SelectionBasisSummaries, SelectedActionKindSummaries, and AppliedActionKindSummaries, so behavior-level and per-authoring-style publication answers can show why a winning governance rule beat the runner-up and which override dimensions only stayed declared versus materially applied without reopening the candidate catalog
the shipped REST governance rule catalogs now also derive rule-centric runtime-effect buckets directly from candidate truth: RestEndpointSuppressionDescriptor now carries MatchedCandidateIds, SuppressedCandidateIds, SkippedCandidateIds, SelectionBases, and grouped SelectionBasisSummaries, while RestEndpointOverrideDescriptor now carries MatchedCandidateIds, SelectedCandidateIds, AppliedCandidateIds, SkippedCandidateIds, SelectionBases, grouped SelectionBasisSummaries, SelectedActionKinds, grouped SelectedActionKindSummaries, AppliedActionKinds, and grouped AppliedActionKindSummaries; the reusable grouped bucket contracts are now RestEndpointGovernanceSelectionBasisSummaryDescriptor and RestEndpointGovernanceOverrideActionKindSummaryDescriptor, so /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and the matching snapshot surfaces can answer one rule’s actual runtime footprint plus grouped candidate provenance without reopening the full candidate catalog
grouped publication answers now also expose grouped host-governance eligibility and skipped-governance truth through HostGovernanceEligibleCandidateIds, HostGovernanceIneligibleCandidateIds, SkippedSuppressionIds, SkippedOverrideIds, and typed RestEndpointPublicationGroupGovernanceSkippedSuppressionSummaryDescriptor / RestEndpointPublicationGroupGovernanceSkippedOverrideSummaryDescriptor entries via SkippedSuppressionSummaries / SkippedOverrideSummaries at both the behavior-group level and inside each AuthoringStyleSummaries entry, so explicit module-DSL ownership that stayed outside host governance remains visible without drilling into each candidate separately and operators can see which ineligible candidates each skipped host rule targeted
when more than one shorthand candidate stays published for one grouped behavior answer, runtime truth should keep the live ASP.NET Core endpoint names deterministic as well as the routes; co-published shorthand candidates now disambiguate their effective endpoint names by authoring style, route shape, and candidate identity when needed while preserving OriginalEndpointName as source shorthand lineage
the shipped REST governance baseline now also exposes IRestEndpointSuppressionRuntimeCatalog, /engine/rest-endpoint-suppressions, /engine/rest-endpoint-suppressions/{suppressionId}, and snapshot.RestEndpointSuppressions, plus IRestEndpointOverrideRuntimeCatalog, /engine/rest-endpoint-overrides, /engine/rest-endpoint-overrides/{overrideId}, and snapshot.RestEndpointOverrides; RestApi:Suppressions and RestApi:Overrides are host-level ASP.NET Core publication-governance surfaces for descriptor-backed module-owned shorthand candidates, not engine-core route-authoring contracts
the shipped RestApi:Suppressions baseline remains suppression-only by design and shorthand-first by default: it can hide MapProfile<TBehavior>() candidates plus generated shorthand candidates from MapGeneratedProfiles(...) and MapGeneratedProfileGroups(...) before precedence resolution, it can now target one exact candidate through CandidateIds, it can refine Behaviors/Modules targeting further with optional ApiVersionMajors, Methods, RelativePatterns, RouteGroupPrefixes, OpenApiDocumentNames, TagNames, EndpointNames, HostGovernanceScopes, BindingFallbackModes, and exact original explicit TargetBindings, those selector refiners and candidate ids all match the original candidate shape before override actions are applied, EndpointNames targets ProjectedEndpoint.OriginalEndpointName, HostGovernanceScopes targets OriginalProjection.HostGovernanceScope, and explicit module DSL/manual module-owned REST endpoints still remain authoritative unless the owning route group explicitly opts into host governance and the matching host rule explicitly targets authoring style behavior-module-dsl; omitted AuthoringStyles still keep existing host rules shorthand-only by default, and suppression still does not rewrite route shape, HTTP method, input binding, or OpenAPI document membership
the shipped RestApi:Overrides baseline follows that same two-gate model and now supports the same optional exact CandidateIds targeting plus selector refiners ApiVersionMajors, Methods, RelativePatterns, RouteGroupPrefixes, OpenApiDocumentNames, TagNames, EndpointNames, HostGovernanceScopes, BindingFallbackModes, and exact original explicit TargetBindings, plus override actions ApiVersionMajor, OpenApiDocumentName, Method, bounded published RouteGroupPrefix, constrained relative Pattern, RequiredCapabilityKey, ClearRequiredCapability, constrained explicit Bindings, RemovedBindingProperties, binding resets through ClearBindings, host-governed preserved fallback through PreserveImplicitQueryFallback, endpoint metadata EndpointName / Summary / Description, OpenAPI tag name TagName, and typed RestEndpointOverrideBindingMode: it can retarget governable candidates to another effective API major version, published OpenAPI document name, HTTP method, published route-group prefix, relative route pattern, required Cephalon capability boundary, intentionally cleared capability boundary, endpoint metadata, OpenAPI tag name, preserved implicit query-fallback intent, and/or explicit binding plan, records the applied rule through RestEndpointCandidateRuntimeDescriptor.AppliedOverrideId, keeps the original source shape visible through OriginalProjection, now also keeps host-governance eligibility visible through RestEndpointCandidateProjectionDescriptor.AllowsHostGovernance, keeps the original authored governance scope visible through RestEndpointCandidateProjectionDescriptor.HostGovernanceScope and published OriginalProjection.HostGovernanceScope, matches all of its selectors against that original candidate identity before override actions are applied, with EndpointNames targeting ProjectedEndpoint.OriginalEndpointName and HostGovernanceScopes targeting OriginalProjection.HostGovernanceScope, drives ASP.NET Core materialization through the same effective projection shape reported by the runtime catalogs, keeps the /api/v{major} route segment and OpenAPI document name aligned when version changes, directly rewrites the effective document name when OpenApiDocumentName changes, keeps mapped route truth aligned when pattern changes, keeps effective tag truth aligned when TagName changes, lets RouteGroupPrefix move the published governable group only when it stays beneath the active REST root, contains no placeholders, and does not silently change effective API-version truth, only re-derives the effective document name from ApiVersionMajor when the authored group did not pin one explicitly through .WithOpenApiDocumentName(...), allows placeholder-preserving rewrites by default, now also allows placeholder renames when the effective explicit route-binding plan covers the renamed placeholder set exactly, now also allows placeholder removals when the original projection already exposes full explicit route-binding coverage and the effective explicit binding plan keeps every affected original route-bound property explicitly bound, and now also allows placeholder additions 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, for POST/PUT/PATCH already part of the original deterministic remaining-body fallback surface, for candidates with no explicit binding plan already part of the original implicit query-fallback surface, or for explicit-binding shorthand candidates whose remaining source query surface was intentionally preserved either by the source profile or by a winning override that sets PreserveImplicitQueryFallback = true; no-explicit-plan candidates now also preserve their remaining implicit query-fallback surface when hosts add only partial explicit bindings, and preserved fallback answers are now published through typed RestEndpointCandidateProjectionDescriptor.BindingFallbackMode and RestEndpointRuntimeDescriptor.BindingFallbackMode values backed by RestEndpointBindingFallbackMode, where PreserveSourceImplicitFallback models source implicit-query preservation and PreserveRemainingBodyFallback models deterministic remaining request-body fallback for explicit body-capable binding plans; additive metadata.bindingFallbackMode = preserve-source-implicit-fallback and metadata.bindingFallbackMode = preserve-remaining-body-fallback remain compatibility-only metadata, exact original explicit TargetBindings now also lets hosts match the source binding-plan identity by descriptor-set equivalence before later override rewrites run, it still rejects broader implicit-property promotion beyond that constrained body-fallback-plus-bounded-query-fallback-plus-source-or-host-preserved-explicit-query-fallback path, treats BindingMode as a split contract where host config stays wire-name-only with replace-explicit or merge-explicit while runtime JSON preserves unspecified only for ClearBindings rules that omitted an explicit mode and normalizes other omitted modes to replace-explicit or merge-explicit, defaults Bindings to replace-explicit, now also allows BindingMode = merge-explicit so hosts can upsert changed explicit bindings or withdraw selected original explicit bindings through RemovedBindingProperties while still letting unbound route placeholders and remaining request-body fields fill object properties deterministically, now also allows ClearBindings so a host can return an authored explicit binding plan to the implicit route/query/body baseline when that effective route still binds truthfully, and now also treats Bindings plus TargetBindings binding sources as stable wire-name-only route / query / header / body surfaces across host config and runtime JSON; it still fails fast when one rule sets both RequiredCapabilityKey and ClearRequiredCapability, when replace-explicit is paired with removals, when one merge rule tries to both remove and override the same property, when ClearBindings is paired with Bindings, RemovedBindingProperties, PreserveImplicitQueryFallback, or an explicit BindingMode, when a removal targets a property the source candidate never bound explicitly, when the effective method-plus-binding plan is invalid, or when a placeholder rename, removal, addition, or ClearBindings reset would rely on inference, lose explicit binding coverage, or promote an implicit property outside those bounded fallback surfaces; explicit module DSL and manual module-owned REST endpoints still stay authoritative by default, and explicit module DSL only enters that override boundary when both the owning route group and the matching host rule opt in
the shipped REST performance baseline now also includes RestEndpointProjectionGovernanceBenchmarks.BuildMapGovernedRestCatalogs; it exercises generated/profile/DSL precedence, shorthand-only authoring-policy enforcement while explicit module DSL remains authoritative, grouped generated module ownership, suppression and override selection, explicit .ApiVersion(...) group authority over host version rewrites, and preserved implicit query fallback, and scripts/validate-release.ps1 plus the guardrail catalog now treat that benchmark as part of the default release-validation lane
the shipped benchmark smoke path now uses a shared BenchmarkInProcessShortRunConfig across every benchmark class so repo-local mirrored .build/* benchmark projects do not break BenchmarkDotNet project resolution during validate-release, and the default benchmark filter set now includes the hot-path benchmark classes so guardrail validation stays truthful against the full shipped catalog
the REST benchmark closeout also fixed Cephalon.Behaviors.SourceGen to emit the BehaviorRestProfileDescriptor.PreserveImplicitQueryFallback named argument with the correct casing, so source-generated shorthand REST metadata remains buildable when that fallback option is declared
a deliberate HostGovernanceScopes selector now also counts as a primary host-governance target beside CandidateIds, Behaviors, and Modules, so scope-only suppression or override rules can govern one authored route-group label without restating behavior or module ids while empty-selector rules still fail fast
when a host configures suppression or override rules that target an explicit module-DSL candidate before that route group opts into governance, runtime truth should expose that near-match explicitly instead of pretending no rule targeted the route; candidates and published behavior-backed endpoints now keep ordered SkippedSuppressionIds and SkippedOverrideIds visible while Matched* remains empty, so operators can distinguish governance-ineligible explicit ownership from an actual selector miss or winning governance outcome
when RouteGroupPrefix remaps only one shorthand candidate in an authored route group, ASP.NET Core materialization should split the effective published group boundaries so actual HTTP routes, /engine/rest-endpoint-candidates, /engine/rest-endpoints, /engine/rest-endpoint-overrides, and snapshot keep one shared runtime truth instead of reporting a remapped candidate that still materializes under the old group
when TagName retags only one shorthand candidate in an authored route group, ASP.NET Core materialization should also split the effective published groups by route-group prefix plus document name plus tag so actual endpoint tag metadata, OpenAPI grouping, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and snapshot keep one shared runtime truth instead of reporting a retagged candidate that still materializes inside the original mixed-tag group
shorthand REST governance selectors must keep matching the original shorthand candidate identity rather than the already-rewritten published answer; that identity now includes CandidateIds, ApiVersionMajors, Methods, RelativePatterns, RouteGroupPrefixes, OpenApiDocumentNames, TagNames, EndpointNames, HostGovernanceScopes, BindingFallbackModes, and exact original explicit TargetBindings so hosts can target one of several same-behavior candidates without losing runtime truth, including the original shorthand endpoint name through ProjectedEndpoint.OriginalEndpointName, the original authored governance scope through OriginalProjection.HostGovernanceScope, the original shorthand binding-fallback identity through the stable wire names preserve-source-implicit-fallback and preserve-remaining-body-fallback, plus the original explicit binding-plan identity through full descriptor-set equivalence
the shipped suppression-rule baseline now fails fast when a rule omits all of CandidateIds, Behaviors, and Modules, so typo-shaped config cannot silently turn into a global shorthand kill switch
when more than one REST suppression rule matches the same candidate, the shipped resolver now picks the most specific rule deterministically by preferring candidate-targeted rules first, then by fewer targeted candidate ids, then by populated target dimensions (CandidateIds, Behaviors, Modules, ApiVersionMajors, Methods, RelativePatterns, RouteGroupPrefixes, OpenApiDocumentNames, TagNames, EndpointNames, HostGovernanceScopes, BindingFallbackModes, TargetBindings), then by preferring behavior-targeted rules over module-only rules, then by narrower authoring-style scope, then by fewer total selector values, then by stable rule id ordering
when more than one REST override rule matches the same candidate, the shipped resolver uses that same candidate-targeted specificity model, including EndpointNames, HostGovernanceScopes, and TargetBindings as populated target dimensions, before falling back to stable rule id ordering
when more than one REST suppression or override rule matches one shorthand candidate, runtime truth now keeps the full ordered match set visible through MatchedSuppressionIds and MatchedOverrideIds while SuppressedBySuppressionId continues to identify the selected suppression winner, AppliedOverrideId continues to identify winning override rules that materially changed the effective answer, and SelectedOverrideId now identifies the winning override rule even when post-materialization reconciliation proves that winner was a runtime no-op
when more than one REST suppression or override rule matches one shorthand candidate, runtime truth should also surface the earliest decisive specificity answer through SuppressionSelectionBasis or OverrideSelectionBasis so operators can see why the selected rule beat the runner-up instead of reverse-engineering the precedence chain from ordered ids alone
published REST endpoint applied-override provenance should only mark a rule as applied when that rule’s own capability or endpoint-metadata action family materially changed the published answer; capability-only or metadata-only no-op matches should remain selected-only even when ASP.NET Core still normalizes other runtime metadata around the endpoint
when REST governance suppresses a shorthand candidate, runtime truth should point at the governing rule id rather than pretending another candidate won; RestEndpointCandidateRuntimeDescriptor.SuppressedBySuppressionId is now the canonical distinction from precedence-based SuppressedByCandidateId
when REST governance retargets a shorthand candidate through version, method, route, binding, or endpoint-metadata override, runtime truth should point at the governing rule id rather than hiding the decision inside the final endpoint shape; RestEndpointCandidateRuntimeDescriptor.AppliedOverrideId is now the canonical trace for that override
when REST governance rewrites shorthand EndpointName, Summary, or Description, the same effective values should drive ProjectedEndpoint, actual ASP.NET Core endpoint metadata, /engine/rest-endpoints, and snapshot.RestEndpoints; metadata-only no-op rules should not claim they changed the published answer
when REST governance clears shorthand EndpointName, Summary, or Description through ClearEndpointName, ClearSummary, or ClearDescription, the effective candidate, actual ASP.NET Core endpoint metadata, /engine/rest-endpoints, and snapshot.RestEndpoints answer should all agree on null while OriginalEndpointName, OriginalSummary, and OriginalDescription still preserve the source shorthand lineage
when REST governance rewrites shorthand TagName, the same effective answer should drive ProjectedEndpoint.Tags, actual ASP.NET Core endpoint tag metadata, /engine/rest-endpoints, and snapshot.RestEndpoints while OriginalProjection.TagName still preserves the source shorthand lineage
when REST governance rewrites shorthand OpenApiDocumentName, the same effective answer should drive ProjectedEndpoint.OpenApiDocumentName, actual ASP.NET Core endpoint-group metadata, /engine/rest-endpoints, and snapshot.RestEndpoints while OriginalProjection.OpenApiDocumentName still preserves the source shorthand lineage
when published candidate or endpoint runtime truth is reconciled after ASP.NET Core materialization, metadata-only same-value rewrites, same-value document rewrites, same-value tag rewrites, and metadata clears against source metadata the owning module already set or removed should keep MatchedOverrideIds visible while leaving AppliedOverrideId empty on /engine/rest-endpoint-candidates, /engine/rest-endpoints, and the matching snapshot answers
when published candidate or endpoint runtime truth is reconciled after ASP.NET Core materialization, reorder-only equivalent binding-plan rewrites should also keep MatchedOverrideIds visible while leaving AppliedOverrideId empty, and that same semantic binding-set comparison should remain shared with projection reuse so the source explicit binding order stays authoritative on the final projected answer
when post-materialization reconciliation proves a matched shorthand override rule was a runtime no-op, /engine/rest-endpoint-candidates, /engine/rest-endpoints, and the matching snapshot answers should keep AppliedOverrideId empty but still surface the winning rule through SelectedOverrideId plus OverrideSelectionBasis so operators can distinguish “no rule won” from “a rule won but changed nothing” and still understand why that rule won
Cephalon.Behaviors.Http now also publishes stable startup diagnostics for shorthand and explicit REST governance through /engine/diagnostics source Cephalon.Behaviors.Http with event ids 5200-5206 for governance suppression, authoring-policy suppression, precedence suppression, applied overrides, no-op override matches, preserved binding fallback, and skipped explicit-governance visibility; when the runtime candidate registry is active, published-endpoint logging should reconcile against post-materialization truth so no-op published endpoints do not claim they changed the runtime answer, event 5200 now also echoes the decisive SuppressionSelectionBasis wire name, events 5202 and 5203 now also echo the decisive OverrideSelectionBasis wire name plus selected-versus-applied override action-kind wire names so the startup log story matches the runtime-catalog truth, event 5204 now follows whichever typed BindingFallbackMode was actually preserved while also echoing the same stable fallback-mode wire name published by RestEndpointBindingFallbackModeExtensions.GetWireName(), including both preserve-source-implicit-fallback and preserve-remaining-body-fallback, event 5205 now records authoring-policy suppression through the stable kinds disallowed-authoring-style, not-allowed-authoring-style, and preferred-authoring-style-selected, and event 5206 now records when explicit module-DSL candidates kept SkippedSuppressionIds and SkippedOverrideIds because the original projection did not allow host governance
RestEndpointBindingFallbackModeExtensions.GetWireName() plus TryParseWireName(...) are now the canonical public bridge for the stable RestEndpointBindingFallbackMode wire names used by JSON serialization and additive metadata.bindingFallbackMode; host adapters and tests should use that helper instead of maintaining independent hardcoded fallback-mode strings
ASP.NET Core RestApi:Suppressions and RestApi:Overrides now also treat BindingFallbackModes as a wire-name-only config surface: use preserve-source-implicit-fallback and preserve-remaining-body-fallback, and fail fast instead of silently accepting PascalCase enum-member aliases
when REST governance rewrites shorthand RequiredCapabilityKey or clears it through ClearRequiredCapability, the same effective answer should drive ProjectedEndpoint.RequiredCapabilityKey, actual ASP.NET Core endpoint metadata, /engine/rest-endpoints, and snapshot.RestEndpoints; RequireCapability(...) and ClearRequiredCapability() now both treat the last declared capability boundary registration as authoritative so a later host override can supersede or intentionally remove an earlier shorthand configureEndpoint guard instead of stacking or silently retaining it
when REST governance clears shorthand explicit bindings through ClearBindings, the same effective answer should drive ProjectedEndpoint.BindingDescriptors, actual ASP.NET Core request composition, /engine/rest-endpoints, and snapshot.RestEndpoints; alias-dependent placeholder routes must fail fast instead of silently surviving through removed explicit route-binding aliases
merge-explicit host overrides must not silently demote source explicit query bindings on non-body shorthand endpoints; withdrawal is allowed only when the source explicitly preserved query fallback, the winning override intentionally sets PreserveImplicitQueryFallback = true, or the host intentionally clears bindings
when published endpoint runtime truth needs to explain shorthand capability governance, /engine/rest-endpoints and snapshot.RestEndpoints should expose both OriginalRequiredCapabilityKey and AppliedOverrideId, and capability-only no-op clear matches should leave the endpoint-level AppliedOverrideId empty when the effective published capability answer does not change
when published candidate runtime truth needs to explain shorthand capability governance, /engine/rest-endpoint-candidates and snapshot.RestEndpointCandidates should keep MatchedOverrideIds visible for capability-only no-op matches but leave AppliedOverrideId empty when ASP.NET Core materialization proves the effective published capability answer did not change, including both no-op clears and same-key capability rewrites
the shipped profile-binding baseline treats explicit route/query/header/body bindings as overrides rather than as an exclusive binder mode, still lets unbound route placeholders and request bodies fill remaining object properties deterministically, and fails fast when a JSON body tries to overwrite a property reserved by an explicit non-body binding
the current profile-binding hardening baseline now rejects invalid binding metadata at build time through ABT0019 through ABT0025, now also rejects malformed BehaviorRestProfileAttribute.RelativePattern placeholder syntax earlier through ABT0026, now also rejects BehaviorRestProfile(PreserveImplicitQueryFallback = true) without any explicit bindings through ABT0027, removes enum-ordinal assumptions from source-generated GetRestProfiles() output, and re-checks route-pattern validity, route-placeholder truth, and preserved implicit-query fallback requirements during BehaviorRestProfileResolver normalization so MapProfile<TBehavior>() stays fail-fast even when it falls back to direct attribute metadata instead of generated hints
the current profile-binding hardening baseline now also gives BehaviorRestMethod stable get / post / put / patch / delete wire names through BehaviorRestMethodExtensions plus BehaviorRestBindingSource stable route / query / header / body wire names through BehaviorRestBindingSourceExtensions, and source-generated GetRestProfiles() validation now keys off those canonical wire-name vocabularies while still emitting the resolved enum member names, so future package-surface refactors can preserve behavior-authored REST metadata by keeping the wire-name contracts stable
the current profile-binding hardening baseline now also reuses those same canonical method and binding-source wire names in runtime attribute-fallback and explicit binding-plan normalization errors, so JSON serialization, source generation, MapProfile<TBehavior>() fallback, and operator/developer guidance all point at one stable behavior-authored REST vocabulary instead of mixing canonical wire names with generic runtime wording
the current behavior-authored REST method-guidance baseline now also reuses the canonical method wire names in non-body method body-binding rejections and unsupported REST method parser failures, so runtime fallback, body-capability validation, and parser guidance no longer leak Get/Delete-style member names or generic method wording back into the operator contract
the current shorthand-governance operator baseline now also locks SuppressedByAuthoringPolicyKind onto canonical disallowed-authoring-style, not-allowed-authoring-style, and preferred-authoring-style-selected wire names across /engine/rest-endpoint-candidates, candidate-by-id payloads, and snapshot.RestEndpointCandidates, so authoring-policy suppression truth does not depend on raw enum serialization behavior
the current public REST baseline now fails fast when two resolved public endpoints collide on the same HTTP method + route pattern; future shorthand or convention publication must compose through the same projection, runtime-catalog, and collision-validation pipeline instead of bypassing it
any future broader config-override model beyond the shipped original-shape candidate-id-plus-selector-targeting baseline across version, method, route-group prefix, document name, tag name, binding fallback, capability, binding replacement, merge-explicit upsert/withdraw, clear-bindings reset, PreserveImplicitQueryFallback, placeholder rename/removal/addition, implicit body-fallback promotion, bounded implicit query-fallback promotion, partial explicit-override query-fallback preservation, and source-or-host-preserved explicit-query-fallback promotion should land only if runtime truth remains explicit and introspectable; any future implicit-property-promotion route model beyond that constrained body-fallback-plus-bounded-query-fallback-plus-source-or-host-preserved-explicit-query-fallback path, or any broader binding-rewrite model beyond the current replace-plus-merge-explicit upsert-plus-withdraw approach, should extend the same candidate, suppression, and override catalogs instead of bypassing them, and any future additional shorthand sources should land only when that runtime truth stays visible
exact-versus-prefix behavior-subtree governance truth must stay aligned not only in /engine/rest-endpoint-candidates, /engine/rest-endpoint-suppressions, /engine/rest-endpoint-overrides, and snapshot, but also in /engine/rest-endpoint-publication-groups, /engine/rest-endpoint-authoring-policies, the direct grouped/operator runtime catalogs, and the matching per-authoring-style summaries; broader prefix rules should remain visible as matched-only outcomes when a narrower exact behavior rule wins selection, and prefix-targeted rules that hit explicit module-DSL behavior ids without AllowHostGovernance() should stay visible as skipped outcomes rather than disappearing as if they never matched
when a shorthand profile declares explicit bindings and intentionally preserves source implicit query fallback, host overrides can now promote that remaining query-bound property set into added route placeholders, and candidate plus published runtime truth now clear BindingFallbackMode once the effective binding plan fully consumes that preserved surface
REST runtime truth may now intentionally differ between OriginalProjection and ProjectedEndpoint for BindingFallbackMode; that split is the contract, not drift
explicit manual module-owned REST now joins that same engine-owned runtime catalog and duplicate-route guard baseline; freeform host routes outside IRestModule remain out of scope unless Cephalon deliberately adopts them later
Engine:Behaviors is no longer a per-behavior REST topology contract; keep it focused on behavior discovery and auto-registration
when a module explicitly owns behaviors, prefer BehaviorModuleBase for process-only modules and RestBehaviorModuleBase when the same module also exposes some of those behaviors over REST; keep raw IRestModule implementations for REST modules that do not dispatch through behaviors
prefer BehaviorModuleBase when a module explicitly owns behaviors but does not expose a public REST surface
prefer RestBehaviorModuleBase when the same module owns behaviors and exposes some of them over REST
prefer the single-surface REST DSL on RestBehaviorModuleBase: public behaviors.Group(...).MapGet/MapPost/... routes imply ownership automatically, while behaviors.Internal<TBehavior>() is the explicit path for internal-only or custom/manual-route behaviors in the same module
keep one bounded context in one module when possible; do not split modules only to separate internal behaviors from REST-exposed behaviors
Engine:Behaviors:AutoRegister is now an opt-in fallback rather than the default behavior-ownership path; prefer explicit module ownership and only turn scanning back on when a host intentionally wants convention-based discovery
keep behavior return contracts transport-neutral by default: prefer raw TOut for simple success paths, prefer Result<T> for expected non-success branches, keep BehaviorResult<T> as a compatibility alias during the transition, and treat ResultModel<T> / ResultModelError as an optional REST wire-format policy rather than the universal engine contract
the optional REST result-envelope wire contract now uses problem-style type plus HTTP status instead of the older status_code; ApiRoutes:ResultEnvelope:Enabled = false must continue to leave ASP.NET Core ProblemDetails and protocol-native envelopes alone, while true may translate REST-prefixed problem responses into ResultModelError
prioritize core engine quality, contract clarity, performance, security, and maintainability before pushing deeper agentic, AI, or broader multi-platform runtime follow-through; future-tech expansion should build on a solid engine baseline instead of driving premature core-contract churn
standardize provider-pack settings by family instead of forcing one property shape on every pack: use ConnectionStringName plus ConnectionString for connection-string-native providers, use UriName plus Uri for URI-first providers, resolve named entries from the root ConnectionStrings or Uris sections as appropriate, fail fast when both named and inline settings are configured together, and keep topology-first providers such as Cassandra and Qdrant explicit
preferred long-term data direction: keep Engine:Data as the logical app-model and capability-selection layer, use the shipped engine-owned Engine:Databases baseline for physical roles, migrations, and topology introspection, do not make mandatory DbContext base classes the primary engine contract, and keep durable audit history as additive provider-pack follow-through instead of overloading the narrow Cephalon.Audit baseline
the current database-topology role-reference contract is intentionally narrow: Write and Read stay concrete root targets, while Outbox and History can explicitly reuse write through UseRole and still layer local schema/runtime overrides; broader role graphs are a later follow-through only if runtime and migration truth stay explicit
the current database-topology baseline now has five complementary operator answers: /engine/databases is the raw engine-owned topology projection, /engine/database-roles plus snapshot.DatabaseRoles are the resolved runtime catalog for requested versus resolved roles, UseRole, co-location, consumers, audit-history metadata, and provider-contributed live role health, /engine/database-migrations plus snapshot.DatabaseMigrations are the resolved runtime catalog for logical migration targets, their current status, typed resolved-role runtime state, and provider-added command guidance, /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook are the canonical engine-owned ordered migration answer with generated counts, ordered steps, physical-target execution groups, grouped command sets, combined command-batch templates, startup-apply truth, resolved-role identity, and selected production-versus-manual command guidance, and /engine/database-topology plus snapshot.DatabaseTopology are the canonical engine-owned posture summary, advisory, and ordered action-plan answer over role health, migration status, and production-guidance completeness
the current durable audit-history baseline is Cephalon.Audit.EntityFramework, driven by Engine:Audit:History plus a selected engine-owned database role that defaults to history, with Engine:Audit:History:Export, Engine:Audit:History:Retention, IAuditHistoryReader, IAuditHistoryExporter, /engine/audit-history, /engine/audit-history/export, and showcase-facing /api/v1/showcase/audit/history plus /api/v1/showcase/audit/history/export routes now proving read, bounded NDJSON export, and retention follow-through while the showcase sample keeps configured WriteDb / ReadDb / HistoryDb roots for Docker-backed runs plus an explicit Outbox -> write dependent role reference
the showcase database-topology operator projection now layers six complementary sample-level answers on top of the engine routes: a readiness summary, an ordered operator action plan, derived operator insights, an ordered migration playbook, a Markdown operator brief export at /api/v1/showcase/system/database-topology/brief, and a downloadable self-describing handoff package at /api/v1/showcase/system/database-topology/handoff that now includes a package README.md, a machine-readable handoff-manifest.json, the Markdown brief, and the raw projection payload; the engine-owned /engine/database-topology posture is now the baseline for readiness, engine-level advisories, and the engine portion of the ordered action plan, the engine-owned /engine/database-migration-playbook route is now the baseline for ordered migration guidance plus physical-target execution-group truth, grouped command sets, and combined command batches, and sample-only follow-through stays limited to read-model drift, backlog, retry pressure, disabled-sync truth, and repo-root command adaptation instead of re-deriving core role/migration posture locally, while the projection still preserves engine-owned action categories plus source role or migration ids instead of collapsing those stable fields away
the showcase sample now always wires Cephalon.Data.EntityFramework plus Cephalon.Audit.EntityFramework; Docker mode keeps the configured PostgreSQL root roles, while non-Docker local/test runs rewrite Write, Read, and History to unique in-memory targets so /engine/database-roles, /engine/database-migrations, and showcase-facing audit-history routes stay truthful without external infrastructure
Cephalon.Data.EntityFramework now contributes live role-probe metadata through the engine-owned database-role catalog, including connectivity outcome plus pending-migration diagnostics for registered DbContext roles, while dependent targets such as outbox -> write can inherit resolved-role runtime truth without losing their logical role identity
the engine-owned database runtime contract now also includes RoleProbeFreshnessSeconds; Cephalon.Data.EntityFramework uses the merged shared-plus-role runtime selection to cache probe results per logical role, treats 0 as the explicit no-cache answer, defaults to a 30-second freshness window when none is configured, invalidates cached probes when migration runtime state changes, and now projects stable cache/freshness/source timing through the typed DatabaseRoleProbeDescriptor contract on DatabaseRoleRuntimeDescriptor.Probe plus DatabaseRoleDescriptor.Probe, while keeping probeSource, probeFreshnessOrigin, probeFreshUntilUtc, and probeAgeSeconds metadata only for additive provider details and compatibility. The showcase database-topology projection now consumes the typed probe surface directly instead of parsing those stable keys locally
the engine-owned migration catalog now carries typed provider-added command templates through DatabaseMigrationCommandDescriptor; Cephalon.Data.EntityFramework uses that surface to publish bundle/script/update guidance per logical role, DatabaseMigrationDescriptor now also carries typed RecommendedExecutionOrder hints plus typed resolved-role runtime fields so operator playbooks and projections do not hardcode write / read / history locally or parse only metadata dictionaries for stable engine-owned answers, and the command descriptor now also carries typed operator metadata such as ToolId, ExecutionCategory, and WorkingDirectoryHint so sample or host projections do not have to infer those reusable fields only from metadata dictionaries, while staying honest that true bundle/script generation or execution orchestration is still a later slice
the engine-owned migration runtime now also includes DatabaseMigrationOperationalPlaybook, DatabaseMigrationOperationalStep, DatabaseMigrationOperationalExecutionGroup, DatabaseMigrationOperationalExecutionGroupCommand, DatabaseMigrationOperationalExecutionGroupCommandBatch, 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, selecting one production-recommended and one manual/direct command path per target when available, grouping logical targets into physical-target execution batches when possible, surfacing those grouped command paths directly, and now also publishing deterministic combined command-batch templates for the selected production and manual paths, while the showcase sample consumes that engine-owned playbook directly and limits its own logic to repo-root runnable command adaptation plus sample-only read-model follow-through
the engine-owned database role plus migration-playbook contract now also surfaces stable physical-target identity and shared-target coordination truth; /engine/database-roles plus snapshot.DatabaseRoles now answer PhysicalTargetId, PhysicalTargetDisplayName, and physical co-location for logical roles that share one database, /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook now answer coordination counts, physical-target execution groups, grouped command sets, combined command batches, and per-step coordinated migration ids and hints, and /engine/database-topology now adds shared-physical-target migration-coordination advisories plus action-plan entries when pending or failed logical migration work spans one physical database, while the showcase sample consumes those answers directly in /showcase, the Markdown brief, and the handoff package instead of inferring shared-database risk locally
durable audit-history export is intentionally NDJSON-only for the first shipped slice, configuration-gated through Engine:Audit:History:Export, and bounded by MaxEntries; replay UX, richer export formats, and delivery automation remain separate follow-through work
the current eventing operator baseline now splits configured dispatch ownership from live dispatch state explicitly: IEventDispatchRuntimeDescriptorCatalog plus /engine/event-dispatch-runtimes answer what managed dispatch runtimes are active and what outbox/runtime ids they own, while IEventDispatchRuntimeCatalog plus /engine/event-dispatches answer the latest reported dispatch outcome, retry intent, timestamps, and totals per outbox path; both sets also flow into /engine/snapshot as EventDispatchRuntimes and EventDispatchStates
the current engine-owned outbox answer is no longer a static staged-descriptor only: OutboxDescriptor.DispatchPolicy plus IOutboxDispatchPolicyCatalog now carry effective ownership per outbox as disabled, consumer-managed, or runtime-managed, /engine/outboxes is the canonical operator surface for that truth, and eventing/Wolverine runtime surfaces are expected to stay aligned with the same ownership answer instead of re-deriving it ad hoc
the showcase sample now wires Cephalon.Eventing.Wolverine directly so the official wolverine-managed dispatch path stays visible through /engine/event-dispatch-runtimes, /engine/event-dispatches, and the runtime snapshot without custom sample-only operator code
treat EventDispatchRuntimeDescriptor.Summary as the canonical per-runtime aggregate operator answer; keep /engine/event-dispatches as the per-outbox detail surface, and prefer pack-specific runtime surfaces such as Wolverine to consume the canonical summary instead of re-aggregating dispatch state independently
event-subscription execution truth now has first-class public read seams: IEventSubscriptionExecutionBindingCatalog exposes active managed bindings by subscription id, IEventSubscriptionExecutionReadinessCatalog lives in Cephalon.Abstractions.Data and tells whether each declared subscription is runtime-bound, hosted-execution-linked, application-managed-state, or declared-only, /engine/event-subscription-readiness plus snapshot.EventSubscriptionExecutionReadiness carry the operator answer, and EventSubscriptionRuntimeMetadataKeys keeps the event-subscriptions ownership, readiness, and runtime-state metadata stable for operator consumers; an empty binding catalog plus declared-only readiness is a valid application-managed answer and Wolverine remains an optional provider-managed proof rather than an engine requirement
when a provider pack truthfully stages durable outbox messages and can persist dispatch outcomes, register IEventDispatchStore alongside IOutbox so consumer-managed and adapter-managed dispatch can reuse the same provider contract without host-specific glue
current provider-native dispatch-store coverage now includes Entity Framework, MongoDB, Redis, Elasticsearch, OpenSearch, Neo4j, Qdrant, NATS, and Cassandra; Cassandra now uses a deterministic message-sharded pending-dispatch index so wide-column workloads can answer due-event queries truthfully without pretending to be a globally ordered queue, while ClickHouse now stays explicit as a staging-only outbox with DispatchPolicy.PolicyId = unsupported until a truthful mutable pending-dispatch design exists
phase 11 resilience work now has the contract-first baseline plus shipped follow-through slices: Engine:Resilience, AppProfile.Resilience, and /engine/resilience remain the public source of truth for requested Retry, Timeout, CircuitBreaker, Bulkhead, and RateLimiting intent, ASP.NET Core projects effective public-HTTP enforcement through IRateLimitingRuntimeCatalog, /engine/rate-limiting, and snapshot.RateLimitingPolicies with operator/docs route exclusions plus endpoint-scoped override metadata from Engine:Resilience:RateLimiting:Overrides, and that same host runtime now keeps long-lived stream-versus-connection truth visible there through transportKind, transportSemantics, enforcementMoment, and longLivedTransportIds while the built-in GraphQL adapter maps explicit /graphql, /graphql/schema, /graphql-sse, and /graphql-ws surfaces under the shared prefix contract. The shared GraphQL transport authoring layer now also exposes ConfigureGraphQLMutation(...) and ConfigureGraphQLSubscription(...), so modules can contribute mutation and subscription roots without dropping to raw request-executor hooks, while the built-in hosting coverage now proves configured schema, SSE, and WebSocket routes through real SDL downloads, text/event-stream payloads, and graphql-transport-ws frames instead of path-only reachability. Cephalon.Behaviors now projects effective behavior-execution retry, timeout, circuit-breaker, bulkhead, and rate-limiting enforcement through IBehaviorResilienceRuntimeCatalog, /engine/behavior-resilience, and snapshot.BehaviorResiliencePolicies. That behavior-execution layer now also resolves additive Engine:Resilience:BehaviorExecution:Overrides entries with behavior+transport > behavior > transport > default precedence, keeps explicit disable overrides visible in the runtime catalog, lets the REST helper layer translate the still-effective timeout or open-circuit answers into 503 plus bulkhead or behavior-execution rate-limiting answers into 429 with per-route OpenAPI metadata, and now shares that same resilience-fault translation across the generic behavior HTTP GraphQL, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket adapters so those transports keep protocol-native rate-limiting, timeout, and open-circuit envelopes instead of flattening shared behavior-dispatch rejections into generic failures. It also carries explicit behavior-authored idempotency through BehaviorIdempotencyAttribute so Resolve(behaviorId, transportId) can surface retry eligibility as eligible, ineligible, or unknown while the shared pipeline only replays explicitly idempotent transient failures with effective retry backoff/jitter settings. When a REST route keeps both the ASP.NET Core endpoint limiter and the behavior-dispatch limiter active, the host limiter rejects first and surfaces the host-owned 429 envelope unless an Engine:Resilience:RateLimiting:Overrides entry disables that endpoint policy for the targeted behavior/transport pair; broader non-REST resilience-envelope semantics beyond the shipped 429/503 baseline remain later slices
the built-in pattern taxonomy now includes onion-architecture, anti-corruption-layer, strangler-fig, and backend-for-frontend; future architecture guidance should treat those as shipped runtime-app-model descriptors rather than pending recommendations only, while remembering that broader provider-specific ingress or edge automation, broader non-REST frontend materialization, and provider-specific feature-flag packs are still separate work
the current phase 12 strangler-fig baseline follows the same contributor/registry/catalog pattern as other engine surfaces: modules or hosts contribute StranglerFigRouteDescriptor entries, the engine composes them into IStranglerFigRuntimeCatalog and snapshot.StranglerFigRoutes, Engine:Migration:StranglerFig overlays deterministic default plus per-route target/progress policy through IStranglerFigMigrationRuntimeCatalog and snapshot.StranglerFigRoutePolicies, and the engine-first ingress follow-through now also projects normalized materialization answers through IStranglerFigIngressRuntimeCatalog and snapshot.StranglerFigIngressRoutes. ASP.NET Core now exposes /engine/strangler-fig, /engine/strangler-fig/runtime, /engine/strangler-fig/ingress, /engine/strangler-fig/resolve, /engine/strangler-fig/cutover, and /engine/strangler-fig/cutover/resolve; when Engine:Migration:StranglerFig:AspNetCore is enabled, rooted local selected endpoints rewrite in-process, absolute HTTP or HTTPS selected endpoints redirect or proxy, and unsupported or opaque selected endpoints fail truthfully with 502 without introducing a second source of cutover truth outside the shared runtime catalogs
the current phase 12 backend-for-frontend baseline follows that same contributor/registry/catalog pattern: modules or hosts contribute BackendForFrontendClientBindingDescriptor entries, Engine:BackendForFrontend:Bindings can contribute the same shape from configuration, the engine composes them into IBackendForFrontendRuntimeCatalog and snapshot.BackendForFrontendBindings, the backend-for-frontend pattern now auto-selects when bindings exist, and ASP.NET Core now exposes /engine/backend-for-frontend plus client/module/transport drill-down routes. The first client-aware REST follow-through now stays on that same truth path too: ASP.NET Core derives IBackendForFrontendRestRuntimeCatalog, /engine/backend-for-frontend/rest-endpoints, and snapshot.BackendForFrontendRestEndpoints from the shared binding catalog plus the published REST endpoint catalog instead of creating host-only truth. The first REST documentation/materialization follow-through also stays on that same truth path: ASP.NET Core now derives IBackendForFrontendRestDocumentRuntimeCatalog, /engine/backend-for-frontend/rest-documents, scope-specific filtered OpenAPI routes, scope-aware Scalar pages, and snapshot.BackendForFrontendRestDocuments from those same shared runtime answers plus the normal host OpenAPI settings instead of inventing a separate documentation registry. Broader non-REST frontend materialization remains later work
the current phase 12 feature-flag baseline follows that same contributor/registry/catalog pattern: hosts can add FeatureFlagDescriptor entries directly, Engine:Features can contribute the same shape from configuration, modules can contribute module-owned flags through IFeatureFlagContributor, and the engine now composes that merged answer into IFeatureFlagRuntimeCatalog, IFeatureToggle, and snapshot.FeatureFlags. ASP.NET Core now exposes /engine/features plus enabled, disabled, source-module, id, and evaluate routes from that same shared truth. Module-contributed flags must declare SourceKind.Module with a matching SourceModuleId, duplicate ids fail composition deterministically, and the current baseline intentionally does not advertise a runtime.feature-flags capability because runtime capability provenance is still module-based
that same phase 12 feature-flag baseline now also has the first shared behavior-consumption follow-through: behavior topology descriptors can carry ordered required feature ids plus owning module identity, the shared pipeline evaluates those gates through IFeatureToggle, source-generated topology literals preserve the same declarations, runtime metadata reports feature-gated behavior counts plus per-behavior required ids, and transport adapters now map the resulting BehaviorFeatureDisabledException into transport-appropriate outcomes instead of inventing a second host-only rollout registry
Cephalon.Eventing.Behaviors is now the explicit phase-12 bridge between ISagaChoreographyPublisher and the shared outbox-backed Cephalon.Eventing publish path; keep choreography authoring ownership in Cephalon.Behaviors.Patterns, keep staged publication ownership in Cephalon.Eventing, and use AddBehaviorEventingBridge() instead of silently wiring choreography handoff through baseline eventing enablement
the current phase 12 saga choreography authoring-helper follow-through stays on that same truth path too: keep higher-level helper ownership in Cephalon.Behaviors.Patterns through ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, SagaChoreographyStepResult<TOutput>, and the typed JSON helper factories on SagaChoreographyPublication; let ChoreographySagaExecutionStrategy normalize those additive contracts into the same ISagaChoreographyPublisher handoff; and do not move serializer, publication, or runtime-source-of-truth ownership into Cephalon.Eventing.Behaviors
AddBehaviorPatterns() defaults are now fallback-friendly (TryAddSingleton / TryAddEnumerable) so explicit saga publisher, saga-store, checkpoint-store, and strategy registrations can coexist with the eventing bridge without registration-order traps; the engine-managed bridge only advertises capability/runtime-surface truth when it owns the effective ISagaChoreographyPublisher registration, while deeper post-composition override truth remains separate future work if hosts need runtime catalogs to observe later service replacement
the current phase 12 durable-execution follow-through stays on the same contributor/registry/catalog path as other engine surfaces: AddBehaviorPatterns() now registers both IDurableExecutionRuntimeCatalog and IDurableExecutionRuntimeStateCatalog, Cephalon.Behaviors.Patterns derives the static catalog from IBehaviorCatalog plus IBehaviorTypeRegistry and reports per-stream live posture from DurableExecutionStrategy itself, Cephalon.Engine now projects both snapshot.DurableExecutions and snapshot.DurableExecutionStates, and ASP.NET Core now exposes /engine/durable-executions plus /engine/durable-executions/runtime drill-down routes; the timer/signal follow-through now keeps pending timer/signal coordination on that same runtime-state catalog through DurableExecutionPendingTimer, DurableExecutionPendingSignal, the waiting posture, and the pending timer/signal filter routes, and the compensation-helper follow-through now keeps operator-facing DurableExecutionCompensationAction metadata on that same runtime-state catalog through the compensation filter routes instead of creating a second workflow registry

Working assumptions for contributors

Unless the code clearly proves otherwise, contributors should assume:

host adapters should stay thin
reusable behavior belongs in engine services, modules, or companion packs rather than in app hosts
deterministic ordering and explicit registration beat ambient discovery magic
any public runtime, package, or diagnostics surface may also have docs, sample, scaffold, template, and validation-script follow-through
hand-authored docs are part of the product and should be kept truthful when shipped behavior changes
documents under docs/* often cross-reference one another, so code changes may require multi-file doc updates across hubs, component pages, operations guides, compatibility guidance, roadmap/backlog notes, and related adoption docs
GitHub Project tracking should stay readable on its own, with complete card descriptions and the expected planning fields filled in so another contributor can understand scope, validation, timing, and dependencies quickly
GitHub Project history should remain traceable from the card itself, including comment-level references to relevant commit ids as work lands
meaningful work should appear in both repo-owned planning/docs surfaces and GitHub Project tracking; if one side is missing, treat the planning record as incomplete
the durable written project record should stay in English so docs, commits, cards, and related planning artifacts read consistently across the repository
XML comments on public contracts are not optional polish; they are part of the supported documentation surface

Current next-look areas

If you need to resume deeper analysis later, the most likely next focus areas are:

Cephalon.Engine runtime, package, trust, and introspection internals
Cephalon.Behaviors and the ABT pipeline, strategies, and transport bindings
REST authoring is now mostly in adoption and closeout mode: keep the engine-first module-owned strategy, grouped shorthand/runtime-truth surfaces, and the cephalon-rest-behavior-module starter stable, and only revisit new publication sources when they preserve ownership, deterministic precedence, and the existing runtime-catalog/operator-story contract
phase 13 now has shipped cell-boundary, cell-route, cell-health-isolation, configuration-driven cell-traffic-automation, provider-aware and edge-aware cell-traffic-automation targeting, the first provider-managed cell traffic materializer baseline, the first edge-runtime cell traffic materializer baseline, richer multi-provider reconciliation over that shared traffic catalog, the first provider-specific control-plane materializer through Cephalon.Edge.KubernetesGateway, the first live Kubernetes Gateway observation overlay through ICellTrafficAutomationMaterializationReportSink plus opt-in observe-only polling, the first owned HTTPRoute apply-and-reconcile baseline through KubernetesGatewayTrafficObservationModes.ApplyAndReconcile, the second provider-specific control-plane materializer through Cephalon.Edge.Traefik, the first live Traefik observation overlay through TraefikTrafficObservationModes plus opt-in observe-only polling, the first owned IngressRoute apply-and-reconcile baseline through TraefikTrafficObservationModes.ApplyAndReconcile, the first provider-native lifecycle execution hardening baseline through ENG-146, the first opt-in provider-native cleanup sweep baseline through ENG-147, the second provider-native CDC runner plus first relational CDC proof through ENG-148, the richer external CDC reporting hardening baseline through ENG-149, the richer provider-native condition-semantics baseline through ENG-150, the third provider-native CDC runner plus first logical-replication streaming proof through ENG-153, the PostgreSQL publication/slot lifecycle plus restart-resume hardening follow-through through ENG-154, the richer external failover/takeover baseline through ENG-155, the richer multi-reporter reconciliation baseline through ENG-156, the stronger reporter takeover/degraded-posture hardening follow-through through ENG-157, and the fourth provider-native CDC runner plus first MySQL binlog proof through ENG-158, which together keep RecreateSlotIfInvalidated, additive slot lifecycle plus failure metadata, inactive invalidated-slot recreation, slot-confirmed-flush resume truth, participant-level reporter truth, stable takeover-state answers, degraded-reason classification, durable MySQL binlogFile|position checkpoints, and bounded initial-position plus resume-mode truth on the same shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces; keep cell-based-architecture as a technology/profile concern instead of a new blueprint, preserve cell ownership through CellBoundaryDescriptor.SourceModuleId, CellRouteDescriptor.SourceModuleId, and CellHealthIsolationDescriptor.SourceModuleId, keep automation overlays additive through Engine:Cells:TrafficAutomation, CellTrafficAutomationRuntimeDescriptor.ProviderId, CellTrafficAutomationRuntimeDescriptor.EdgeNodeIds, CellTrafficAutomationRuntimeDescriptor.ProviderMaterializerId, CellTrafficAutomationRuntimeDescriptor.ProviderMaterializationState, CellTrafficAutomationRuntimeDescriptor.EdgeMaterializerId, CellTrafficAutomationRuntimeDescriptor.EdgeMaterializationState, the derived CellTrafficAutomationRuntimeDescriptor.MaterializationState, and CellTrafficAutomationRuntimeDescriptor.MaterializationConditions, keep traffic materialization grounded in CellTrafficAutomationMaterializationResult, CellTrafficAutomationMaterializationStates, CellTrafficAutomationMaterializationConditionDescriptor, ICellTrafficAutomationProviderMaterializer, ICellTrafficAutomationEdgeMaterializer, and ICellTrafficAutomationMaterializationReportSink, keep provider-managed and edge-managed reconciliation plus deterministic selection rationale on the shared /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface instead of a second traffic registry, keep provider-specific control-plane projection, live observation, owned-route apply semantics, additive cleanup-sweep posture, and typed provider conditions through Cephalon.Edge.KubernetesGateway, KubernetesGatewayTrafficMaterializerOptions, KubernetesGatewayTrafficObservationOptions, KubernetesGatewayTrafficRouteOptions, KubernetesGatewayTrafficObservationModes, providerMaterialization.providerRouteId, and the kubernetes-gateway-traffic-materializations technology surface while remaining truthful about statusSource = configured-intent, statusSource = gateway-api-status, and statusSource = control-plane-apply, keep second-provider projection, live observation, owned-route apply semantics, additive cleanup-sweep posture, and typed provider conditions through Cephalon.Edge.Traefik, TraefikTrafficMaterializerOptions, TraefikTrafficObservationModes, TraefikTrafficObservationOptions, TraefikIngressRouteOptions, TraefikMiddlewareReferenceOptions, providerMaterialization.providerRouteId, and the traefik-ingressroute-traffic-materializations technology surface while remaining truthful about statusSource = configured-intent, statusSource = traefik-ingressroute-observation, and statusSource = control-plane-apply, keep explicit external-conflict versus orphaned-transfer semantics plus merged create / replace / transfer lifecycle truth and additive cleanup summaries on those same provider-specific surfaces instead of a second lifecycle registry, keep data mesh ownership grounded in DataProductDescriptor.SourceModuleId, DomainId, ContractId, and Mode, keep CDC ownership grounded in CdcCaptureDescriptor.SourceModuleId, Provider, SourceId, OutboxId, Mode, ExecutionBinding, and provider-contribution metadata when packs contribute on behalf of another module, keep shared CDC execution grounded in ICdcCapture.CdcCaptureId, CdcCaptureExecutionResult, CdcCaptureExecutionAcknowledgement, ICdcCaptureAcknowledger, IOutbox.OutboxId, data.cdc.execution, /engine/execution-graphs, /engine/hosted-executions, and /engine/runtime-story, keep provider-native CDC execution grounded in data.cdc.mongodb, mongodb-change-stream-capture-flow, mongodb-change-stream-capture-pump, data.cdc.sqlserver, sqlserver-cdc-capture-flow, sqlserver-cdc-capture-pump, data.cdc.postgresql, postgresql-logical-replication-capture-flow, postgresql-logical-replication-capture-pump, data.cdc.mysql, mysql-binlog-capture-flow, mysql-binlog-capture-pump, additive slot lifecycle metadata, durable resume-token plus LSN plus slot-backed logical-replication checkpoints, durable MySQL file-plus-position checkpoints, and the same /engine/cdc-captures*, /engine/cdc-captures/runtime*, and /engine/cdc-capture-runtimes* surfaces, keep execution-topology truth grounded in CdcCaptureExecutionRuntimeDescriptor, CdcCaptureExecutionRuntimeSummary, ICdcCaptureExecutionRuntimeCatalog, DataRuntimeOptions.CdcExecutionRuntimes, /engine/cdc-capture-runtimes, /engine/cdc-captures/execution-runtimes/{executionRuntimeId}, /engine/cdc-captures/runtime/execution-runtimes/{executionRuntimeId}, ICdcCaptureExecutionRuntimeReportSink, and POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports, keep live CDC posture grounded in CdcCaptureRuntimeState plus optional linked OutboxDispatchState, and keep any later provider-specific automation, data-product, CDC execution, or richer traffic-materialization follow-through additive over /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/data-products, /engine/cdc-captures, /engine/cdc-captures/runtime, /engine/cdc-capture-runtimes, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, /engine/technology-surfaces, snapshot.CellBoundaries, snapshot.CellRoutes, snapshot.CellHealthIsolations, snapshot.CellTrafficAutomations, snapshot.DataProducts, snapshot.CdcCaptures, snapshot.CdcCaptureStates, snapshot.CdcCaptureExecutionRuntimes, snapshot.ExecutionGraphs, snapshot.HostedExecutions, and snapshot.OperationalStory
the 2026-04-22 ENG-151 slice shipped the broader dependency-aware teardown baseline: providerMaterialization.cleanup* and provider-specific technology surfaces now publish cleanupStrategy plus primary/dependency cleanup breakdowns, Cephalon.Edge.KubernetesGateway truthfully stays primary-only for owned HTTPRoute sweeps, and Cephalon.Edge.Traefik now sweeps safe owned Middleware and TLSOption dependents in addition to IngressRoute cleanup without inventing a second lifecycle registry
the 2026-04-22 ENG-152 slice shipped the deeper external and edge-aware CDC execution-topology baseline: external reports now keep first-class reporter identity, reporter-lease expiry, and edge-node provenance on the shared runtime-state plus execution-runtime surfaces, while declared runtime policy can now reject conflicting reporters and undeclared edge nodes without inventing a second topology coordinator
the 2026-04-22 ENG-153 slice shipped the PostgreSQL provider-native CDC baseline: Cephalon.Data.Postgres now proves slot-backed logical-replication streaming on the same shared CDC descriptor, runtime-state, execution-runtime, execution-graph, hosted-execution, and runtime-story surfaces already used by MongoDB and SQL Server
the 2026-04-22 ENG-155 slice shipped the richer external and edge-aware CDC failover/takeover baseline: external report ingestion now keeps typed ReporterCoordination on both per-capture and per-execution-runtime surfaces, rejected conflicting reporters are preserved as degraded coordination evidence, accepted post-expiry takeovers now keep previous-owner plus takeover timestamps, and the same shared /engine/cdc-* plus snapshot surfaces now answer active-owner versus expired-lease versus conflicted posture without inventing a second topology coordinator
the 2026-04-22 ENG-156 slice shipped richer multi-reporter reconciliation plus operator-story hardening on that same shared CDC runtime story: reporter coordination now keeps first-class participant-level active, standby, and rejected truth through ReporterParticipants, HasStandbyReporters, and HasRejectedReporters, while accepted takeovers keep previous owners visible as standby evidence and rejected conflicts stay visible without inventing a second coordination registry
the 2026-04-22 ENG-157 slice shipped stronger reporter takeover and degraded-posture hardening on that same shared CDC runtime story: Cephalon.Abstractions now ships CdcCaptureReporterCoordinationIssueReasons plus CdcCaptureReporterTakeoverStates, CdcCaptureReporterCoordinationStatus now carries TakeoverState, DegradedReason, RequiresTakeover, and HasCompletedTakeover, and Cephalon.Data now distinguishes awaiting-takeover, rejected-conflict, and multiple-active ambiguity on the same shared /engine/cdc-* plus snapshot surfaces without inventing a second operator taxonomy
the 2026-04-22 ENG-158 slice shipped the MySQL provider-native CDC baseline: Cephalon.Data.MySql now proves bounded row-event binlog capture, durable binlogFile|position checkpoints, provider-owned execution through mysql-binlog-capture-flow plus mysql-binlog-capture-pump, and shared capture/runtime/execution-story truth on the same /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces already used by MongoDB, SQL Server, and PostgreSQL
the 2026-04-22 ENG-159 slice shipped MySQL-specific lifecycle and resume hardening on that same shared CDC runtime story: MySqlBinlogCaptureOptions now supports ExpectedSourceServerUuid, the Cephalon-managed checkpoint table now keeps additive SourceServerUuid, SourceServerId, GtidExecutedSet, BinlogFormat, and BinlogRowImage metadata, and the same /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces now publish retained-binlog lifecycle posture, source-server identity truth, checkpoint provenance, and GTID observe-only metadata without inventing a MySQL-only lifecycle registry
the 2026-04-22 ENG-160 slice shipped broader external CDC reporter rejoin and stale-conflict cleanup on that same shared runtime story: CdcCaptureReporterCoordinationStatus now exposes additive participant-count helpers, later accepted reports now clear stale rejected-conflict evidence, and completed takeovers stop surfacing previous owners as standby participants once the replacement reporter reaffirms lease ownership while the same shared /engine/cdc-* plus snapshot surfaces keep historical takeover fields available
the 2026-04-22 ENG-161 slice shipped the Oracle provider-native CDC baseline: Cephalon.Data.Oracle now proves committed-only LogMiner capture, bounded SCN-window execution, covering redo plus archive-log selection, durable commitScn|changeScn|rsId|ssn checkpoints, provider-owned execution through oracle-logminer-capture-flow plus oracle-logminer-capture-pump, and shared capture/runtime/execution-story truth on the same /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces already used by MongoDB, SQL Server, PostgreSQL, and MySQL
the 2026-04-22 ENG-162 slice shipped Oracle-specific lifecycle and resume hardening on that same shared CDC runtime story: OracleLogMinerCaptureOptions now supports ExpectedDatabaseId, ExpectedDatabaseUniqueName, and ResumeFromEarliestAvailableScnIfCheckpointUnavailable, the Cephalon-managed checkpoint table now keeps additive DatabaseId, DatabaseUniqueName, ResetLogsChangeNumber, ArchiveLogMode, and SupplementalLogDataMin metadata, and the same /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces now publish databaseIdentity*, archiveLogLifecycle*, and checkpoint-provenance truth without inventing an Oracle-only lifecycle registry
the 2026-04-22 ENG-163 slice shipped broader external and edge-aware CDC operator-story drill-downs on that same shared runtime story: ICdcCaptureRuntimeStateCatalog plus ICdcCaptureExecutionRuntimeCatalog now expose reporter-id, edge-node-id, coordination-state, and degraded-reason filters, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now support reporter-first, edge-first, and degraded-posture operator readback without inventing a second coordination registry
the 2026-04-23 ENG-164 slice shipped the Debezium external managed-connector CDC baseline: Cephalon.Data.Debezium now contributes DebeziumDataOptions, DebeziumConnectorOptions, and DebeziumCaptureOptions, publishes Debezium-managed runtime ownership through the shared /engine/cdc-*, /engine/runtime-story, and snapshot surfaces without faking a hosted execution or execution graph, and auto-registers the shared external runtime report sink whenever Debezium connectors are configured
the 2026-04-23 ENG-165 slice shipped Debezium lifecycle and reconciliation hardening on that same shared CDC runtime story: DebeziumConnectorOptions now supports ManagementMode plus ExpectedTaskCount, Debezium runtime reports now normalize raw connector/task metadata into stable debezium* lifecycle and reconciliation answers, and the shared execution-runtime catalog now promotes runtime-scoped Debezium metadata back onto /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only lifecycle registry
the 2026-04-23 ENG-166 slice shipped richer CDC operator-story rollups on that same shared external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeReporterCoordinationRollup plus CdcCaptureReporterCoordinationBreakdownEntry, CdcCaptureExecutionRuntimeSummary now carries additive ReporterCoordinationRollup, and the shared execution-runtime catalog now projects coordination-state breakdowns, degraded-reason breakdowns, active/standby/rejected reporter ids, and degraded capture ids back onto /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a second coordination registry
the 2026-04-23 ENG-167 slice shipped broader external-runtime reporting-coverage hardening on that same shared runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeReportingCoverageStates plus CdcCaptureExecutionRuntimeReportingCoverageStatus, CdcCaptureExecutionRuntimeSummary now carries additive ReportingCoverage plus HasUnreportedDeclaredCaptures / HasFullCaptureCoverage, and the shared execution-runtime catalog now derives ReportedCdcCaptureIds plus not-bound / unreported / partially-reported / fully-reported posture only from captures that have submitted real observations instead of descriptor-backed placeholder state
the 2026-04-23 ENG-168 slice shipped external-runtime remediation summaries and drill-downs on that same shared runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeRemediationStates, CdcCaptureExecutionRuntimeRemediationCategories, and CdcCaptureExecutionRuntimeRemediationStatus, CdcCaptureExecutionRuntimeSummary now carries additive Remediation plus RequiresRemediation / HasBlockingRemediation, and the shared execution-runtime catalog now derives ready / attention / blocked posture plus active remediation categories from resolved capture ownership instead of only the raw authored runtime descriptor ids
the 2026-04-23 ENG-169 slice shipped the first shared managed-connector governance baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorGovernanceStates, CdcCaptureExecutionRuntimeManagedConnectorGovernanceCategories, CdcCaptureExecutionRuntimeManagedConnectorGovernanceActionIds, and CdcCaptureExecutionRuntimeManagedConnectorGovernanceStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorGovernance, Debezium now normalizes shared managedConnector* metadata beside existing debezium* metadata, and the shared execution-runtime catalog now derives observe-only / future-control-plane / out-of-policy posture plus governance categories and drill-down routes on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only governance registry
the 2026-04-23 ENG-170 slice shipped the first shared desired-versus-observed managed-connector drift baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDriftStates, CdcCaptureExecutionRuntimeManagedConnectorDriftCategories, CdcCaptureExecutionRuntimeManagedConnectorDriftActionIds, and CdcCaptureExecutionRuntimeManagedConnectorDriftStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDrift, Debezium now normalizes declared-versus-reported shared managedConnector* identity metadata beside existing debezium* metadata, and the shared execution-runtime catalog now derives not-applicable / unknown / in-sync / drifted posture plus drift drill-down routes on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only drift registry
the 2026-04-23 ENG-171 slice shipped the first shared managed-connector action-planning baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorActionPlanStates, CdcCaptureExecutionRuntimeManagedConnectorActionPlanCategories, CdcCaptureExecutionRuntimeManagedConnectorActionPlanActionIds, and CdcCaptureExecutionRuntimeManagedConnectorActionPlanStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorActionPlan, and the shared execution-runtime catalog now derives not-applicable / observe / waiting / action-required / blocked posture plus action ids and drill-down routes from the merged remediation, governance, and drift answers on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only action-planning registry
the 2026-04-23 ENG-172 slice shipped the first shared managed-connector write-path readiness baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessStates, CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessCategories, and CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorWritePathReadiness, and the shared execution-runtime catalog now derives not-applicable / deferred / not-ready / ready / blocked posture plus readiness categories and drill-down routes from merged coverage, remediation, governance, drift, and action-planning truth on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only readiness registry
the 2026-04-23 ENG-173 slice shipped the first shared managed-connector preflight baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorPreflightStates, CdcCaptureExecutionRuntimeManagedConnectorPreflightCategories, CdcCaptureExecutionRuntimeManagedConnectorPreflightOperationIds, and CdcCaptureExecutionRuntimeManagedConnectorPreflightStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorPreflight, and the shared execution-runtime catalog now derives not-applicable / deferred / not-ready / ready / blocked posture plus preflight categories and operation ids from merged coverage, remediation, governance, drift, action-planning, and write-path-readiness truth on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only preflight registry
the 2026-04-23 ENG-174 slice shipped the first shared managed-connector dry-run baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDryRunStates, CdcCaptureExecutionRuntimeManagedConnectorDryRunCategories, CdcCaptureExecutionRuntimeManagedConnectorDryRunOperationIds, and CdcCaptureExecutionRuntimeManagedConnectorDryRunStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDryRun, and the shared execution-runtime catalog now derives not-applicable / deferred / blocked / no-op / would-change posture plus dry-run categories and operation ids from merged coverage, remediation, governance, drift, action-planning, write-path-readiness, and preflight truth on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only dry-run registry
the 2026-04-23 ENG-175 slice shipped the first shared managed-connector execution-intent baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentSources, and CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionIntent, and the shared execution-runtime catalog now derives not-applicable / deferred / blocked / operator-action / requires-approval / ready-to-execute posture plus execution-intent categories, operation ids, confidence-source truth, and operator-versus-future-engine follow-through on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only execution planner
the 2026-04-23 ENG-176 slice shipped the first shared managed-connector execution-approval and safety-gating baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalSources, and CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionApproval, and the shared execution-runtime catalog now derives not-applicable / auto-blocked / policy-blocked / approval-required / approval-ready / auto-eligible posture plus execution-approval categories, operation ids, safety-gating source truth, and explicit-approval posture on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only approval registry
the 2026-04-23 ENG-177 slice shipped the first shared managed-connector write-path command-envelope baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeStates, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandEnvelope, and the shared execution-runtime catalog now derives not-applicable / blocked / operator-only / approval-gated / engine-ready posture plus command-envelope categories, operation ids, source truth, target identity, deterministic command fingerprints, and safety flags on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only execution registry
the 2026-04-23 ENG-178 slice shipped the first shared managed-connector command-issuance baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceStates, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandIssuance, and the shared execution-runtime catalog now derives not-applicable / blocked / operator-only / accepted / rejected / issued posture plus command-issuance categories, operation ids, issuance source truth, deterministic issuance fingerprints, and safety flags on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without inventing a Debezium-only issuance registry
the 2026-04-23 ENG-179 slice shipped the first shared managed-connector provider execution-adapter baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterSources, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterStatus, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionRequest, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionResult, ICdcCaptureExecutionRuntimeManagedConnectorExecutionAdapter, and ICdcCaptureExecutionRuntimeManagedConnectorCommandExecutor, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionAdapter, the shared execution-runtime catalog now derives not-applicable / blocked / operator-only / unavailable / ready posture plus execution-adapter categories, operation ids, adapter identity, deterministic adapter fingerprints, and provider-ready safety flags on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes, and Cephalon.Data.Debezium now proves the first provider translation lane by mapping shared pause/resume/restart/delete intent into Debezium or Kafka Connect REST command shape without inventing a second coordinator or control-plane registry
the 2026-04-23 ENG-180 slice shipped the first shared managed-connector execution outcome/history baseline on that same external runtime story: CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionStates now also exposes stable unrecorded, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionResult now carries additive AttemptId, RecordedAtUtc, IsUnrecorded, and HasRecordedOutcome, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandExecution, the shared execution-runtime catalog now projects latest command-execution posture plus bounded recent history through GetByManagedConnectorCommandExecutionState(...), GetByManagedConnectorCommandExecutionOperationId(...), and GetManagedConnectorCommandExecutionHistory(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-executions/{executionState}, /engine/cdc-capture-runtimes/command-executions/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-executions on the existing shared route family without inventing a Debezium-only execution journal
the 2026-04-23 ENG-181 slice shipped the first shared managed-connector retry/idempotency hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandRetryStates, CdcCaptureExecutionRuntimeManagedConnectorCommandRetryCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandRetryOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandRetrySources, and CdcCaptureExecutionRuntimeManagedConnectorCommandRetryStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandRetry, the shared execution-runtime catalog now derives not-applicable / not-needed / duplicate / cooldown / retry-blocked / operator-only / retry-eligible posture plus retry categories, operation ids, source truth, cooldown windows, fingerprint matching, and latest-attempt context through GetByManagedConnectorCommandRetryState(...), GetByManagedConnectorCommandRetryCategory(...), and GetByManagedConnectorCommandRetryOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-retries/{retryState}, /engine/cdc-capture-runtimes/command-retries/categories/{retryCategory}, and /engine/cdc-capture-runtimes/command-retries/operations/{operationId} on the existing shared route family without inventing a Debezium-only retry registry
the 2026-04-23 ENG-182 slice shipped the first shared managed-connector retry-execution policy baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyStates, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyCategories, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyOperationIds, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicySources, and CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorRetryExecutionPolicy, the shared execution-runtime catalog now derives not-applicable / not-needed / cooldown / manual-approval / policy-blocked / operator-only / background-retry-disabled posture plus policy categories, operation ids, source truth, retry fingerprints, cooldown windows, and latest-attempt context through GetByManagedConnectorRetryExecutionPolicyState(...), GetByManagedConnectorRetryExecutionPolicyCategory(...), and GetByManagedConnectorRetryExecutionPolicyOperationId(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/retry-execution-policies/{policyState}, /engine/cdc-capture-runtimes/retry-execution-policies/categories/{policyCategory}, and /engine/cdc-capture-runtimes/retry-execution-policies/operations/{operationId} on the existing shared route family without inventing a Debezium-only retry-policy registry
the 2026-04-24 ENG-183 slice shipped the first shared managed-connector bounded command-journal hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandJournalStates, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandJournalStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandJournal, the shared execution-runtime catalog now derives not-applicable / empty / bounded / truncated / cooldown-active / duplicate-evidence-present / insufficient-for-automation posture plus journal categories, operation ids, source truth, retained-versus-recorded history counts, fingerprint matching, cooldown windows, and latest-versus-oldest retained attempt metadata through GetByManagedConnectorCommandJournalState(...) and GetByManagedConnectorCommandJournalCategory(...), and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-journals/{journalState}, /engine/cdc-capture-runtimes/command-journals/categories/{journalCategory}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-journal on the existing shared route family without inventing a Debezium-only durable journal or second coordinator
the 2026-04-24 ENG-184 slice shipped the first shared managed-connector automatic background retry execution baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionOperationIds, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionSources, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionStatus, and CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionInvocationSources, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorAutomaticRetryExecution, the shared execution-runtime catalog now derives not-applicable / disabled / blocked / eligible / completed posture plus automatic-retry categories, operation ids, source truth, matching approval and destructive-allowance reuse flags, cooldown windows, retry and execution fingerprints, latest automatic-attempt metadata, and operator-versus-automatic invocation-source truth through GetByManagedConnectorAutomaticRetryExecutionState(...), GetByManagedConnectorAutomaticRetryExecutionCategory(...), and GetByManagedConnectorAutomaticRetryExecutionOperationId(...), Cephalon.Data now exposes the opt-in EnableManagedConnectorAutomaticRetryExecution plus ManagedConnectorAutomaticRetryPollingIntervalSeconds host policy and runs the bounded shared automatic retry lane through ManagedConnectorAutomaticRetryHostedService, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/automatic-retries/{automaticRetryState}, /engine/cdc-capture-runtimes/automatic-retries/categories/{automaticRetryCategory}, and /engine/cdc-capture-runtimes/automatic-retries/operations/{operationId} on the existing shared route family without inventing a Debezium-only retry loop, durable distributed scheduler, or second coordinator
the 2026-04-24 ENG-185 slice shipped the first shared managed-connector automatic background retry coordination baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationStates, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationCategories, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationSources, and CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorAutomaticRetryCoordination, the shared execution-runtime catalog now derives not-applicable / single-node / uncoordinated / lease-held / lease-missing / conflicted / operator-only posture plus coordination categories, coordination owner id, active reporter id, reporter-lease timing, execution ownership and topology source truth, and CanExecuteOnCurrentNode through GetByManagedConnectorAutomaticRetryCoordinationState(...), GetByManagedConnectorAutomaticRetryCoordinationCategory(...), and GetByManagedConnectorAutomaticRetryCoordinationOwnerId(...), Cephalon.Data now exposes the host-level ManagedConnectorAutomaticRetryCoordinationOwnerId policy and uses that shared answer to gate both ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/automatic-retry-coordinations/{coordinationState}, /engine/cdc-capture-runtimes/automatic-retry-coordinations/categories/{coordinationCategory}, and /engine/cdc-capture-runtimes/automatic-retry-coordinations/owners/{ownerId} on the existing shared route family without inventing a durable distributed scheduler, a second coordination registry, or a Debezium-only multi-node retry loop
the 2026-04-24 ENG-186 slice shipped the first shared managed-connector durable retry-journal baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityStates, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilitySources, and CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandJournalDurability, the shared execution-runtime catalog now derives not-applicable / in-memory-only / persisted / recovered / recovery-failed / persistence-failed posture plus durability categories, persistence path, persisted-versus-recovered timestamps, retained-versus-recorded history counts, persisted/recovered-history flags, and source truth through GetByManagedConnectorCommandJournalDurabilityState(...) and GetByManagedConnectorCommandJournalDurabilityCategory(...), Cephalon.Data now exposes the host-level ManagedConnectorCommandJournalPersistencePath policy and persists bounded command history through ManagedConnectorCommandExecutionHistoryStore so retry evidence can survive host restart, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/command-journal-durability/{durabilityState}, /engine/cdc-capture-runtimes/command-journal-durability/categories/{durabilityCategory}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-journal-durability on the existing shared route family without inventing a second journal registry, durable distributed scheduler, or Debezium-only persistence subsystem
the 2026-04-24 ENG-187 slice shipped the first shared managed-connector distributed retry lease and cross-node idempotency hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseStates, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseCategories, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseSources, and CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDistributedRetryLease, the shared execution-runtime catalog now derives not-applicable / single-node / lease-held / lease-missing / lease-conflicted / idempotent-safe / idempotency-risk / operator-only posture plus lease categories, coordination-owner and active-reporter identity, retry-fingerprint and bounded-history evidence, durable-store and duplicate-attempt truth, and CanExecuteAutomaticRetryOnCurrentNode through GetByManagedConnectorDistributedRetryLeaseState(...), GetByManagedConnectorDistributedRetryLeaseCategory(...), and GetByManagedConnectorDistributedRetryLeaseOwnerId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that richer cross-node answer instead of raw coordination alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/distributed-retry-leases/{leaseState}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only retry subsystem
the 2026-04-24 ENG-188 slice shipped the first shared managed-connector distributed retry orchestration baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDistributedRetryOrchestration, the shared execution-runtime catalog now derives not-applicable / disabled / operator-only / cooldown / blocked / scheduled / completed posture plus orchestration categories, scheduler identity and polling metadata, owner/reporter identity, retry fingerprint and latest-attempt context, durable-history evidence, and CanScheduleAutomaticRetryOnCurrentNode through GetByManagedConnectorDistributedRetryOrchestrationState(...), GetByManagedConnectorDistributedRetryOrchestrationCategory(...), and GetByManagedConnectorDistributedRetryOrchestrationOwnerId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that richer shared orchestration answer instead of raw lease checks, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/distributed-retry-orchestrations/{orchestrationState}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only scheduler lane
the 2026-04-24 ENG-189 slice shipped the first shared managed-connector richer cross-node idempotency hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCrossNodeIdempotencyHardening, the shared execution-runtime catalog now derives not-applicable / operator-only / idempotent-safe / stale-owner-risk / duplicate-lineage-risk / 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 through GetByManagedConnectorCrossNodeIdempotencyHardeningState(...), GetByManagedConnectorCrossNodeIdempotencyHardeningCategory(...), GetByManagedConnectorCrossNodeIdempotencyHardeningOwnerId(...), and GetByManagedConnectorCrossNodeIdempotencyHardeningRetryFingerprint(...), Cephalon.Data now feeds that richer hardening answer back into distributed retry orchestration so bounded automatic retry scheduling no longer trusts raw lease truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/cross-node-idempotency-hardenings/{hardeningState}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only idempotency subsystem
the 2026-04-24 ENG-190 slice shipped the first shared managed-connector broader multi-node lease-execution baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorMultiNodeLeaseExecution, the shared execution-runtime catalog now derives not-applicable / operator-only / single-node / lease-executable / lease-blocked / lease-conflicted / stale-lease-risk posture plus lease-execution categories, coordination-owner and active-reporter identity, scheduler identity and polling metadata, retry fingerprint, latest automatic-attempt evidence, and CanExecuteAutomaticRetryOnCurrentNode through GetByManagedConnectorMultiNodeLeaseExecutionState(...), GetByManagedConnectorMultiNodeLeaseExecutionCategory(...), and GetByManagedConnectorMultiNodeLeaseExecutionOwnerId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only lease-execution subsystem
the 2026-04-24 ENG-191 slice shipped the first shared managed-connector durable shared scheduler-orchestration baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDurableSharedSchedulerOrchestration, the shared execution-runtime catalog now derives not-applicable / disabled / operator-only / unscheduled / scheduled / lease-blocked / recovery-needed / scheduler-conflicted posture plus scheduler categories, execution-runtime and capture identity, ownership/topology, coordination-owner and active-reporter identity, scheduler identity/kind, polling metadata, retry fingerprint, latest automatic-attempt evidence, durable-history truth, and CanScheduleAutomaticRetryOnCurrentNode through GetByManagedConnectorDurableSharedSchedulerOrchestrationState(...), GetByManagedConnectorDurableSharedSchedulerOrchestrationCategory(...), and GetByManagedConnectorDurableSharedSchedulerOrchestrationOwnerId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader durable shared 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only scheduler subsystem
the 2026-04-24 ENG-192 slice shipped the first shared managed-connector scheduler recovery and execution-hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorSchedulerRecoveryExecutionHardening, the shared execution-runtime catalog now derives not-applicable / operator-only / recovery-ready / recovery-blocked / replaying / execution-hardened / 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, and latest command-execution truth, scheduler identity/kind, retry fingerprint, latest automatic-attempt evidence, durable-history truth, and CanExecuteAutomaticRetryOnCurrentNode through GetByManagedConnectorSchedulerRecoveryExecutionHardeningState(...), GetByManagedConnectorSchedulerRecoveryExecutionHardeningCategory(...), GetByManagedConnectorSchedulerRecoveryExecutionHardeningOwnerId(...), and GetByManagedConnectorSchedulerRecoveryExecutionHardeningRetryFingerprint(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader scheduler recovery and execution-hardening answer instead of durable shared scheduler truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/scheduler-recovery-execution-hardenings/{hardeningState}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only recovery subsystem
the 2026-04-24 ENG-193 slice shipped the first shared managed-connector broader provider-owned write-path execution baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedWritePathExecution, the shared execution-runtime catalog now derives not-applicable / operator-only / provider-executable / provider-blocked / provider-owned-executing / provider-owned-completed / 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 through GetByManagedConnectorProviderOwnedWritePathExecutionState(...), GetByManagedConnectorProviderOwnedWritePathExecutionCategory(...), and GetByManagedConnectorProviderOwnedWritePathExecutionOperationId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only control-plane surface
the 2026-04-24 ENG-194 slice shipped the first shared managed-connector broader provider execution orchestration hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderExecutionOrchestration, the shared execution-runtime catalog now derives not-applicable / operator-only / orchestration-ready / orchestration-blocked / orchestration-executing / orchestration-completed / orchestration-risk posture plus categories, execution-runtime and capture identity, ownership/topology, operation/source, provider-owned write-path plus execution-adapter plus latest-command plus retry-policy plus command-journal plus durable shared scheduler plus scheduler-recovery state, deterministic fingerprints, adapter/provider metadata, and CanOrchestrateProviderExecutionOnCurrentNode through GetByManagedConnectorProviderExecutionOrchestrationState(...), GetByManagedConnectorProviderExecutionOrchestrationCategory(...), and GetByManagedConnectorProviderExecutionOrchestrationOperationId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader provider execution orchestration answer instead of provider-owned write-path truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-execution-orchestrations/{providerExecutionOrchestrationState}, /engine/cdc-capture-runtimes/provider-execution-orchestrations/categories/{providerExecutionOrchestrationCategory}, /engine/cdc-capture-runtimes/provider-execution-orchestrations/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-execution-orchestration on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only orchestration surface
the 2026-04-24 ENG-195 slice shipped the first shared managed-connector provider-owned control-plane ownership baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneOwnership, the shared execution-runtime catalog now derives not-applicable / operator-only / ownership-ready / ownership-blocked / ownership-active / ownership-partial / ownership-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, provider execution orchestration plus provider-owned write-path plus execution-adapter plus latest-command plus retry-policy plus command-journal plus durable shared scheduler plus scheduler-recovery state, deterministic fingerprints, adapter/provider metadata, approval/destructive/change metadata, durable-history evidence, and CanExerciseProviderOwnedControlPlaneOnCurrentNode through GetByManagedConnectorProviderOwnedControlPlaneOwnershipState(...), GetByManagedConnectorProviderOwnedControlPlaneOwnershipCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneOwnershipOperationId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader provider-owned control-plane ownership answer instead of broader provider execution orchestration truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-control-plane-ownership/{providerOwnedControlPlaneOwnershipState}, /engine/cdc-capture-runtimes/provider-owned-control-plane-ownership/categories/{providerOwnedControlPlaneOwnershipCategory}, /engine/cdc-capture-runtimes/provider-owned-control-plane-ownership/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-control-plane-ownership on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only control-plane ownership surface
the 2026-04-24 ENG-196 slice shipped the first shared managed-connector provider-owned control-plane mutation/reconcile baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneMutationReconcile, the shared execution-runtime catalog now derives not-applicable / operator-only / mutation-ready / reconcile-ready / mutation-blocked / reconcile-blocked / mutation-executing / mutation-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, provider-owned control-plane ownership plus provider execution orchestration plus provider-owned write-path plus command-envelope plus command-issuance plus latest-command plus retry-policy plus command-journal state, deterministic fingerprints, adapter/provider metadata, approval/destructive/change metadata, durable-history evidence, and CanMutateOrReconcileOnCurrentNode through GetByManagedConnectorProviderOwnedControlPlaneMutationReconcileState(...), GetByManagedConnectorProviderOwnedControlPlaneMutationReconcileCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneMutationReconcileOperationId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader provider-owned control-plane mutation/reconcile answer instead of broader provider-owned control-plane ownership truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-control-plane-mutation-reconcile/{providerOwnedControlPlaneMutationReconcileState}, /engine/cdc-capture-runtimes/provider-owned-control-plane-mutation-reconcile/categories/{providerOwnedControlPlaneMutationReconcileCategory}, /engine/cdc-capture-runtimes/provider-owned-control-plane-mutation-reconcile/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-control-plane-mutation-reconcile on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only control-plane mutation/reconcile surface
the 2026-04-24 ENG-197 slice shipped the first shared managed-connector provider-owned control-plane provisioning baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneProvisioning, the shared execution-runtime catalog now derives not-applicable / operator-only / provisioning-ready / provisioning-blocked / provisioning-executing / provisioning-partial / provisioning-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, provider-owned control-plane mutation/reconcile plus provider-owned control-plane ownership plus provider execution orchestration plus provider-owned write-path plus command-envelope plus command-issuance plus latest-command plus retry-policy plus command-journal state, deterministic fingerprints, adapter/provider metadata, approval/destructive/change metadata, durable-history evidence, and CanProvisionProviderOwnedControlPlaneOnCurrentNode through GetByManagedConnectorProviderOwnedControlPlaneProvisioningState(...), GetByManagedConnectorProviderOwnedControlPlaneProvisioningCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneProvisioningOperationId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader provider-owned control-plane provisioning answer instead of broader provider-owned control-plane mutation/reconcile truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-control-plane-provisioning/{providerOwnedControlPlaneProvisioningState}, /engine/cdc-capture-runtimes/provider-owned-control-plane-provisioning/categories/{providerOwnedControlPlaneProvisioningCategory}, /engine/cdc-capture-runtimes/provider-owned-control-plane-provisioning/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-control-plane-provisioning on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only provisioning surface
the 2026-04-24 ENG-198 slice shipped the first shared managed-connector provider-owned control-plane apply-and-reconcile execution baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecution, the shared execution-runtime catalog now derives not-applicable / operator-only / apply-and-reconcile-ready / apply-and-reconcile-blocked / apply-and-reconcile-executing / apply-and-reconcile-completed / apply-and-reconcile-risk posture plus categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, provider-owned control-plane provisioning plus provider-owned control-plane mutation/reconcile plus provider-owned control-plane ownership plus provider execution orchestration plus provider-owned write-path plus command-envelope plus command-issuance plus latest-command plus retry-policy plus command-journal state, deterministic fingerprints, adapter/provider metadata, approval/destructive/change metadata, durable-history evidence, and CanExecuteProviderOwnedControlPlaneApplyAndReconcileOnCurrentNode through GetByManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionState(...), GetByManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionOperationId(...), Cephalon.Data now gates both ManagedConnectorAutomaticRetryHostedService and automatic command execution through that broader provider-owned control-plane apply-and-reconcile execution answer instead of broader provider-owned control-plane provisioning truth alone, and Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-owned-control-plane-apply-and-reconcile-executions/{applyAndReconcileExecutionState}, /engine/cdc-capture-runtimes/provider-owned-control-plane-apply-and-reconcile-executions/categories/{applyAndReconcileExecutionCategory}, /engine/cdc-capture-runtimes/provider-owned-control-plane-apply-and-reconcile-executions/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-owned-control-plane-apply-and-reconcile-execution on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only apply-and-reconcile execution surface
the 2026-04-24 ENG-199 slice shipped the first shared managed-connector provider-owned control-plane dependency-aware apply-and-reconcile hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardening, the shared execution-runtime catalog now derives not-applicable / operator-only / dependency-ready / dependency-blocked / dependency-degraded / apply-and-reconcile-hardened / 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only dependency-hardening surface
the 2026-04-24 ENG-200 slice shipped the first shared managed-connector provider-owned control-plane dependency-aware provisioning and mutation hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardening, the shared execution-runtime catalog now derives not-applicable / operator-only / dependency-ready / provisioning-blocked / mutation-blocked / dependency-degraded / provisioning-hardened / mutation-hardened / 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only provisioning/mutation dependency-hardening surface
the 2026-04-24 ENG-201 slice shipped the first shared managed-connector provider-specific control-plane materializer follow-through baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerStates, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderSpecificControlPlaneMaterializer, the shared execution-runtime catalog now derives not-applicable / operator-only / materializer-unavailable / materializer-ready / materializer-selected / materializer-executing / 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only materializer surface
the 2026-04-24 ENG-202 slice shipped the first shared managed-connector provider-specific control-plane dependency-aware teardown and mutation-execution hardening baseline on that same external runtime story: Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningStatus, CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, the shared execution-runtime catalog now derives not-applicable / operator-only / dependency-ready / teardown-blocked / mutation-execution-blocked / dependency-degraded / teardown-hardened / mutation-execution-hardened / 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}, /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 on the existing shared route family without inventing a second coordinator, second registry, or Debezium-only teardown/mutation-execution surface
the 2026-04-24 ENG-203 slice shipped the next shared provider-specific identity drill-down follow-through on that same external runtime story: ICdcCaptureExecutionRuntimeCatalog now exposes provider-surface and connector selectors for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/provider-surfaces/{providerSurfaceId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/connectors/{connectorId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/provider-surfaces/{providerSurfaceId}, and /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/connectors/{connectorId}, and the shared runtime story can now drill directly into Debezium Kafka Connect REST provider-surface plus connector identity without inventing a second provider-specific registry or Debezium-only operator surface
the 2026-04-25 ENG-204 slice hardened provider-specific worker identity normalization on that same shared runtime story: Cephalon.Data.Debezium now falls back from raw workerId metadata to the stable external reporterId when normalizing provider-specific materializer observations, the shared execution-runtime catalog now resolves the best available provider-specific control-plane worker id from normalized provider-specific metadata plus active reporter truth, and both ManagedConnectorProviderSpecificControlPlaneMaterializer plus ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening now keep stable worker identity and WorkerIdentityVisible posture visible on the existing shared surfaces even when Debezium reports omit an explicit workerId
the 2026-04-25 ENG-205 slice shipped the next shared provider-specific identity drill-down follow-through on that same external runtime story: ICdcCaptureExecutionRuntimeCatalog now exposes worker-id selectors for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/workers/{workerId} and /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/workers/{workerId}, and the shared runtime story can now drill directly into Debezium Kafka Connect REST worker identity without inventing a second provider-specific registry or Debezium-only operator surface
the 2026-04-25 ENG-206 slice shipped the next shared provider-specific transport identity drill-down follow-through on that same external runtime story: ICdcCaptureExecutionRuntimeCatalog now exposes transport-kind selectors for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/transports/{transportKind} and /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/transports/{transportKind}, and the shared runtime story can now drill directly into Debezium Kafka Connect REST transport identity without inventing a second provider-specific registry or Debezium-only operator surface
the 2026-04-25 ENG-207 slice shipped the next shared provider-specific dependency-identity drill-down follow-through on that same external runtime story: ICdcCaptureExecutionRuntimeCatalog now exposes connect-cluster, connector-class, and source-provider selectors for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, Cephalon.AspNetCore now publishes matching /connect-clusters/{connectClusterId}, /connector-classes/{connectorClass}, and /source-providers/{sourceProviderId} drill-downs on those same two shared route families, and the shared runtime story can now drill directly into Debezium Kafka Connect dependency identity without inventing a second provider-specific registry or Debezium-only operator surface
the 2026-04-25 ENG-208 slice shipped the next shared provider-specific current-node drill-down follow-through on that same external runtime story: ICdcCaptureExecutionRuntimeCatalog now exposes current-node selectors for ManagedConnectorProviderSpecificControlPlaneMaterializer plus overall, teardown, and mutation-execution current-node selectors for ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening, Cephalon.AspNetCore now publishes matching /current-nodes/{canUseOnCurrentNode}, /current-nodes/{canExecuteOnCurrentNode}, /current-nodes/teardowns/{canExecuteTeardownOnCurrentNode}, and /current-nodes/mutation-executions/{canExecuteMutationExecutionOnCurrentNode} drill-downs on the existing shared route families, and the shared runtime story can now drill directly into blocked-versus-executable provider-specific node posture without inventing a second provider-specific registry or Debezium-only operator surface
the 2026-04-25 ENG-209 slice shipped the next phase-7 external-adoption follow-through on the CLI-driven install-and-bootstrap path: Cephalon.Cli now extends cephalon doctor with --app-root <path> so adopters can validate a generated app root from the same first-run command path, DoctorCommand now proves the scaffolded .slnx, Directory.Packages.props Cephalon package baseline, NuGet.config cephalon source plus package-source mapping, seeded local ./.cephalon/packages feed or replaced non-local source, generated host project, and CephalonFolder.pubxml profile before restore, run, publish, or deployment work, success output now returns copy/paste-ready Set-Location, dotnet restore, and dotnet run next steps for that app root, and the root README, getting-started guide, CLI component docs, CLI package README, template-pack README, focused tooling coverage, and generated reference docs now stay aligned with that same generated-app bootstrap doctor contract
the 2026-04-25 ENG-210 slice shipped the next framework-readiness follow-through on that same external-adoption lane: scripts/deployment-mode-support.json now carries the machine-readable trim / Native AOT / single-file support contract, scripts/validate-dotnet-readiness.ps1 now projects and validates that manifest back through the readiness JSON plus Markdown reports, and the docs hub, readiness guide, compatibility guide, and package-publishing guidance now keep the same manifest-backed support story explicit without widening current repo truth beyond not-claimed
the 2026-04-25 ENG-211 slice shipped the next CLI adoption follow-through on that same external-adoption lane: Cephalon.Cli now packages the existing deployment-mode support manifest as an embedded tool resource, cephalon doctor now 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 adopters already use for SDK/runtime/bootstrap verification, and the getting-started guide, CLI component docs, CLI package README, template-pack README, root README, and focused tooling coverage now stay aligned with that packaged support-contract story
the 2026-04-25 ENG-212 slice shipped the next generated-app adoption follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now inspects the generated host target framework against the stable net10.0 shipping floor plus the .NET 11 assessment-only readiness lane, compares generated PublishTrimmed, PublishAot, and PublishSingleFile settings from the generated host project plus CephalonFolder.pubxml against the packaged deployment-mode support contract, and keeps stable-versus-readiness-versus-out-of-contract generated-app posture visible from the same generated-app bootstrap command path before restore, publish, or deployment work begins
the 2026-04-25 ENG-213 slice shipped the next generated-app deployment follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated Dockerfile plus the shipped container-image, Azure Container Apps, and Kubernetes deployment assets, compares generated 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
the 2026-04-25 ENG-214 slice shipped the next generated-app deployment follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the shipped Windows Service, IIS, Azure App Service, and Linux systemd deployment assets, compares those generated published-output deployment scripts and units against the current host identity, and keeps self-hosted plus hosted deployment-asset posture visible before published-output deployment work begins
the 2026-04-25 ENG-215 slice shipped the next generated-app deployment follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the shipped compose.yaml and otel-collector-config.yaml local orchestration 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 generated local orchestration posture visible before local docker compose up --build work begins
the 2026-04-25 ENG-216 slice shipped the next generated-app documentation-surface follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated Configurations/AddOpenApi.json and Configurations/AddReferenceDocs.json assets, compares the generated OpenAPI title plus hosted reference-doc enablement, route, directory, and default-document settings against an explicit split-config baseline, and keeps /scalar plus optional hosted reference-doc posture visible before teams rely on those docs surfaces
the 2026-04-25 ENG-217 slice shipped the next generated-app split-config follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated Configurations/AddEngine.*.json assets plus Configurations/Observability/Development.json, compares explicit scaffolded app-model, engine-feature, observability, localization, and development Serilog defaults against that split-config baseline, and keeps generated runtime plus docs plus telemetry configuration posture visible before teams rely on those defaults
the 2026-04-25 ENG-218 slice shipped the next generated-app host-bootstrap follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the scaffolded Program.cs bootstrap source plus the generated host-project PackageReference set and Configurations/**/*.json copy/publish baseline, compares explicit AddCephalonProjectConfigurations, observability wiring, and MapCephalon seams against that scaffolded host bootstrap, and keeps host startup plus build/publish bootstrap posture visible before teams rely on edited startup code
the 2026-04-25 ENG-219 slice shipped the next generated-app starter-test follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated test project plus scaffolded Architecture/CompositionSmokeTests.cs and Features/*BehaviorSpecifications.cs placeholders, compares composition smoke plus Given/When/Then starter seams against the shipped scaffold contract, and keeps generated test-harness posture visible before teams replace those files with real specs
the 2026-04-25 ENG-220 slice shipped the next generated-app guidance-doc follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated root README.md, Configurations/README.md, and deployment README.md assets, compares scaffolded package-source, split-config, publish, deployment, and local-orchestration instructions against the shipped doctor contract, and keeps generated human-facing run/publish/deploy guidance visible before teams follow those docs literally
the 2026-04-25 ENG-221 slice shipped the next generated-app local package-feed guidance follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated .cephalon/packages/README.md asset, compares scaffolded local package-feed seeding plus shared-feed replacement instructions against the shipped doctor contract, and keeps generated package-bootstrap guidance visible before teams seed packages or replace the cephalon source
the 2026-04-25 ENG-222 slice shipped the next generated-app container deployment-script follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated deploy/container-image/publish-image.ps1, deploy/azure-container-apps/deploy-up.ps1, and deploy/kubernetes/apply.ps1 assets, compares Dockerfile plus NuGet.config plus host-project/source-root plus image placeholder plus namespace plus manifest-root seams against the shipped doctor contract, and keeps executable container deployment-script posture visible before teams run those shipped scripts literally
the 2026-04-25 ENG-223 slice shipped the next generated-app Kubernetes manifest follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated deploy/kubernetes/kustomization.yaml, deploy/kubernetes/namespace.yaml, deploy/kubernetes/deployment.yaml, and deploy/kubernetes/service.yaml assets, compares scaffolded namespace plus labels plus image placeholder plus env plus probe plus ClusterIP service seams against the shipped doctor contract, and keeps platform-neutral Kubernetes manifest posture visible before teams rely on those shipped manifests literally
the 2026-04-25 ENG-224 slice shipped the next generated-app teardown and service-manager environment follow-through on that same external-adoption lane: cephalon doctor --app-root <path> now validates the generated deploy/windows-service/remove-service.ps1, deploy/iis/remove-site.ps1, and deploy/linux/systemd/<App>.env assets, compares scaffolded Windows Service stop/delete flow, IIS site/app-pool teardown flow, and Linux systemd environment plus telemetry override hints against the shipped doctor contract, and keeps teardown plus service-manager environment posture visible before teams rely on those shipped operational assets literally
the 2026-04-25 ENG-225 slice shipped the next scenario-driven adoption follow-through on that same external-adoption lane: scripts/validate-generated-app-adoption.ps1 now replays the external cold-start path through temporary package-feed publish, dotnet tool install of Cephalon.Cli, cephalon doctor, scaffold outside the repository, generated local package-feed seeding, cephalon doctor --app-root <path>, restore, build, run, and runtime route probes, while publish-package-artifacts.ps1 now preserves an existing output README.md so generated local package-feed guidance survives package refreshes
the 2026-04-25 ENG-226 slice shipped the matching template-pack parity follow-through on that same external-adoption lane: scripts/validate-template-pack-adoption.ps1 now replays the external cold-start dotnet new path through temporary package-feed publish, dotnet tool install of Cephalon.Cli, isolated Cephalon.TemplatePack install plus dotnet new list cephalon through a custom hive, cephalon doctor with CEPHALON_DOCTOR_TEMPLATE_HIVE, template-pack scaffold outside the repository, generated local package-feed seeding, cephalon doctor --app-root <path>, restore, build, run, and runtime route probes, while cephalon doctor --app-root now accepts template-pack project-root starters instead of requiring only the CLI scaffold layout
the 2026-04-25 ENG-227 slice shipped the matching out-of-tree package parity follow-through on that same external-adoption lane: scripts/validate-out-of-tree-package-adoption.ps1 now replays the external package path through temporary package-feed publish, dotnet tool install of Cephalon.Cli, cephalon doctor, scaffold outside the repository, generated local package-feed seeding, Cephalon.ReferenceModule.Operations pack plus cephalon package stage, generated Engine:Discovery:PackageDirectories plus Engine:PackagePolicy and Engine:Trust patching, cephalon doctor --app-root <path>, restore, build, run, and staged-package runtime plus route probes, so the repo now proves out-of-tree package trust/load truth from the same external-adoption lane
the 2026-04-25 ENG-228 slice shipped the higher-assurance signed-governance follow-through on that same external-adoption lane: scripts/validate-signed-package-governance.ps1 now replays the external package path through temporary package-feed publish, dotnet tool install of Cephalon.Cli, cephalon doctor, scaffold outside the repository, generated local package-feed seeding, Cephalon.ReferenceModule.Operations pack plus deterministic detached-signature repack plus cephalon package stage, generated Engine:Discovery:PackageDirectories plus stricter Engine:PackagePolicy and Engine:Trust:TrustedSignaturePublicKeys patching, cephalon doctor --app-root <path>, restore, build, run, signed-package runtime plus route probes, and a tampered-package denial path so the repo now proves detached-signature trust/load truth from the same external-adoption lane
the 2026-04-26 ENG-229 slice shipped the matching certificate-chain signed-governance follow-through on that same external-adoption lane: scripts/validate-signed-package-governance.ps1 now supports both PublicKey and CertificateChain trust modes, scripts/validate-signed-package-certificate-chain-governance.ps1 now replays the external package path with Engine:Trust:TrustedSignatureCertificates plus Engine:Trust:TrustedSignatureCertificateAuthorities, and the same runtime/package surfaces now prove trusted-certificate-chain verification plus certificateThumbprint truth while a tampered signed package is still denied before module activation
the 2026-04-28 ENG-233 slice shipped the first managed retrieval proof: Cephalon.Retrieval now keeps source material application-owned through IKnowledgeDocumentProvider while Cephalon owns one in-process lexical indexing/query path through IKnowledgeIndexer, IKnowledgeQueryEngine, and IKnowledgeIndexCatalog; /engine/technology-surfaces and /engine/snapshot now report provider readiness, indexing/query ownership, freshness state, document/query counts, latest outcomes, and lastQueryFingerprint plus query length instead of raw query text, while vector databases, embeddings, durable/distributed indexes, rerankers, provider-specific semantic search, and distributed scheduler coordination remain future companion work; opt-in in-process background reindexing later shipped in ENG-270
the 2026-04-28 ENG-234 slice shipped the multi-tenancy governance-boundary split: Cephalon.MultiTenancy now adds tenant-governance-boundaries beside tenant-resolution, keeps the base package’s current ownership to configuration-driven tenant resolution plus ambient context, and separates membership, invitation, domain ownership, and tenant-governance workflows from the base package instead of implying runtime ownership there
the 2026-04-28 ENG-235 slice shipped the first concrete governance companion proof: Cephalon.MultiTenancy.Governance adds AddMultiTenancyGovernance(...), host-defined and module-contributed TenantMembershipDescriptor membership cataloging, tenant/principal-kind/principal-id isolated membership evaluation outcomes (allowed, no-membership, suspended, expired, missing-role, disabled), tenancy.membership.catalog, tenancy.membership.evaluation, diagnostics 4510-4511, and the aggregate tenant-memberships technology surface without taking over domain verification, approval/remediation, durable stores, identity-provider synchronization, or tenant administration
the 2026-04-28 ENG-236 slice shipped the second concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds host-defined and module-contributed TenantInvitationDescriptor invitation cataloging, tenant/invitation plus invitee-kind/invitee-id isolated validation outcomes (valid, not-found, accepted, revoked, expired, invitee-mismatch, missing-role, disabled), tenancy.invitation.catalog, tenancy.invitation.validation, diagnostics 4512-4513, and the aggregate tenant-invitations technology surface without taking over invitation delivery, public onboarding, invitation storage, domain verification, approval/remediation, identity-provider synchronization, or tenant administration at the time; invitation storage later shipped in ENG-242
the 2026-04-28 ENG-237 slice shipped the third concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds host-defined and module-contributed TenantDomainOwnershipDescriptor declared domain-ownership cataloging, tenant/domain isolated validation outcomes (valid, not-found, tenant-mismatch, pending, rejected, suspended, expired, disabled), tenancy.domain-ownership.catalog, tenancy.domain-ownership.validation, diagnostics 4514-4515, and the aggregate tenant-domain-ownership technology surface without taking over DNS/HTTP proof collection, domain lifecycle automation, public onboarding, durable domain stores at the time, approval/remediation action decisions, identity-provider synchronization, or tenant administration; durable domain-ownership storage later shipped in ENG-243
the 2026-04-28 ENG-238 slice shipped the fourth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds host-defined and module-contributed TenantGovernanceActionDescriptor approval/remediation action cataloging, tenant/action/action-kind/subject isolated decision outcomes (allowed, not-found, tenant-mismatch, action-kind-mismatch, subject-mismatch, pending-approval, rejected, remediation-required, expired, disabled), tenancy.governance-action.catalog, tenancy.governance-action.decision, diagnostics 4516-4517, and the aggregate tenant-governance-actions technology surface, while workflow execution was left to the follow-up now shipped in ENG-239
the 2026-04-29 ENG-239 slice shipped the fifth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantGovernanceActionWorkflow, workflow request/result contracts, command/outcome vocabularies, in-process runtime action state, tenant/action-kind/subject guarded transitions (request, approve, reject, require-remediation, mark-remediated, expire), tenancy.governance-action.workflow, diagnostics 4518-4519, and tenant-governance-actions metadata for workflow ownership, runtime action count, durable-store ownership, and notification-delivery ownership
the 2026-04-29 ENG-240 slice shipped the sixth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantGovernanceActionStore, an in-memory default action store, opt-in file-backed JSON durability through MultiTenancyGovernanceOptions.GovernanceActionStoreFilePath, store-failed workflow outcomes when persistence fails, tenancy.governance-action.store, diagnostics 4520-4521, and tenant-governance-actions metadata for action-store kind, durability, ownership, and durable-store ownership without taking over durable membership/invitation/domain stores at the time; durable membership storage was then narrowed and shipped in ENG-241
the 2026-04-29 ENG-241 slice shipped the seventh concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantMembershipStore, an in-memory default membership store, opt-in file-backed JSON durability through MultiTenancyGovernanceOptions.MembershipStoreFilePath, tenancy.membership.store, and tenant-memberships metadata for runtime membership count, membership-store kind, durability, ownership, and durable-store ownership without taking over invitation durability or domain stores at the time; invitation storage was later narrowed and shipped in ENG-242
the 2026-04-29 ENG-242 slice shipped the eighth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantInvitationStore, an in-memory default invitation store, opt-in file-backed JSON durability through MultiTenancyGovernanceOptions.InvitationStoreFilePath, tenancy.invitation.store, and tenant-invitations metadata for runtime invitation count, invitation-store kind, durability, ownership, and durable-store ownership without taking over invitation delivery, durable domain stores at the time, distributed or provider-backed membership/invitation/action-store backends, notification/delivery, remediation execution beyond state transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, public onboarding, or tenant administration
the 2026-04-29 ENG-243 slice shipped the ninth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipStore, an in-memory default domain-ownership store, opt-in file-backed JSON durability through MultiTenancyGovernanceOptions.DomainOwnershipStoreFilePath, tenancy.domain-ownership.store, and tenant-domain-ownership metadata for runtime domain ownership count, domain-ownership-store kind, durability, ownership, and durable-store ownership without taking over domain verification workflow execution at the time; that workflow was later narrowed and shipped in ENG-244
the 2026-04-29 ENG-244 slice shipped the tenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipVerificationWorkflow, workflow request/result contracts, in-process runtime domain-ownership state transitions, tenant/domain and verification-method guarded commands (request, verify, reject, suspend, expire), store-failed persistence outcomes, tenancy.domain-ownership.workflow, diagnostics 4522-4525, and tenant-domain-ownership metadata for verification-workflow ownership plus DNS/HTTP proof-collection ownership boundaries without taking over DNS/HTTP proof collection or external polling, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration
the 2026-04-29 ENG-245 slice shipped the eleventh concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipProofEvaluator, proof-evaluation request/result contracts, proof outcome and metadata-key vocabularies, exact trimmed expected-versus-observed proof comparison, verify/reject workflow mutation, SHA-256 proof fingerprints, tenancy.domain-ownership.proof-evaluation, diagnostics 4526-4527, and tenant-domain-ownership metadata for proof-evaluation ownership without taking over DNS/HTTP proof collection or external polling, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration
the 2026-04-29 ENG-246 slice shipped the twelfth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipProofChallengeIssuer, proof-challenge request/result contracts, proof-challenge outcome and metadata-key vocabularies, secure generated cephalon-domain-proof-* values, DNS TXT / HTTP publication hints, expected-proof metadata persistence through ITenantDomainOwnershipStore, tenancy.domain-ownership.proof-challenge, diagnostics 4528-4529, and tenant-domain-ownership metadata for proof-challenge issuance ownership without taking over DNS publication, HTTP publication, DNS/HTTP proof collection, or external polling at the time; on-demand HTTP file proof collection was later narrowed and shipped in ENG-248, and HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-247 slice shipped the thirteenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipProofPublicationPlanner, proof-publication plan request/result contracts, proof-publication outcome and metadata-key vocabularies, DNS TXT record/value or HTTP file path/content/content-type instruction generation from expected proof metadata and challenge hints, optional plan metadata persistence through ITenantDomainOwnershipStore, tenancy.domain-ownership.proof-publication-plan, diagnostics 4530-4531, and tenant-domain-ownership metadata for proof-publication planning ownership without taking over DNS publication, HTTP publication, DNS/HTTP proof collection, or external polling at the time; on-demand HTTP file proof collection was later narrowed and shipped in ENG-248, and HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-248 slice shipped the fourteenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipHttpProofCollector, HTTP proof-collection request/result contracts, HTTP proof-collection outcome and metadata-key vocabularies, HTTPS-by-default host-matched bounded HTTP file collection, safe URI/status/length/fingerprint metadata, tenancy.domain-ownership.http-proof-collection, diagnostics 4532-4533, and tenant-domain-ownership metadata for HTTP proof-collection ownership without taking over DNS publication, HTTP publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration at the time; DNS TXT proof collection was later narrowed and shipped in ENG-250, and HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-249 slice shipped the fifteenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipProofVerificationRunner, proof-verification request/result contracts, proof-verification outcome and metadata-key vocabularies, one orchestration entry point for challenge issuance, publication planning, supplied-proof evaluation, and optional HTTP file collection, tenancy.domain-ownership.proof-verification-runner, diagnostics 4534-4535, and tenant-domain-ownership metadata for proof-verification runner ownership without taking over DNS publication, HTTP publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration at the time; DNS TXT proof collection was later narrowed and shipped in ENG-250, and HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-250 slice shipped the sixteenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipDnsTxtProofCollector, DNS TXT proof-collection request/result contracts, DNS TXT proof-collection outcome and metadata-key vocabularies, bounded DNS-over-HTTPS JSON collection through an explicit resolver endpoint, normalized TXT answer evaluation through the existing proof evaluator, safe resolver/status/count/fingerprint metadata, tenancy.domain-ownership.dns-txt-proof-collection, diagnostics 4536-4537, and tenant-domain-ownership metadata for configured DNS TXT proof-collection ownership without taking over DNS publication, HTTP publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration at the time; bounded on-demand proof polling was later narrowed and shipped in ENG-251, automatic background proof polling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-251 slice shipped the seventeenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipProofPollingRunner, proof-polling request/result contracts, proof-polling outcome and metadata-key vocabularies, bounded catalog selection for pending/rejected HTTP file and DNS TXT declarations, verification-runner delegation, default batch-limit options, tenancy.domain-ownership.proof-polling-runner, diagnostics 4538-4539, and tenant-domain-ownership metadata for proof-polling runner ownership plus externalProofPollingOwnership = cephalon-managed and backgroundProofPollingOwnership = application-managed without taking over DNS publication, HTTP publication, provider mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration at the time; automatic background scheduling was later narrowed and shipped in ENG-252, and HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-252 slice shipped the eighteenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds opt-in automatic background tenant-domain ownership proof polling through ITenantDomainOwnershipProofPollingRuntimeCatalog, TenantDomainOwnershipProofPollingRuntimeSnapshot, TenantDomainOwnershipProofPollingHostedService, background polling enable/interval/startup/source options, startup and interval scheduling over the bounded proof-polling runner, tenancy.domain-ownership.proof-background-polling, diagnostics 4540-4543, and tenant-domain-ownership metadata for background proof-polling enabled state, interval, batch, run counts, latest outcome, and cephalon-managed ownership when enabled without taking over DNS publication, HTTP publication, provider mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant administration at the time; HTTP file proof publication was later narrowed and shipped in ENG-253
the 2026-04-29 ENG-253 slice shipped the nineteenth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantDomainOwnershipHttpProofPublisher, ITenantDomainOwnershipHttpProofPublicationCatalog, HTTP proof-publication request/result/descriptor/outcome contracts, publication metadata keys, HTTP path/content/content-type materialization through the existing publication planner, tenancy.domain-ownership.http-proof-publication, diagnostics 4544-4545, and tenant-domain-ownership metadata for HTTP proof-publication ownership/count; Cephalon.MultiTenancy.Governance.AspNetCore is the optional ASP.NET Core adapter that serves published proof files while DNS publication, provider mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed governance storage, notification/delivery, remediation execution beyond state transitions, identity-provider synchronization, public onboarding, or tenant-admin UI remain outside this proof
the 2026-04-29 ENG-254 slice shipped the twentieth concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantAdministrationWorkflow, tenant-administration workflow request/result/command/outcome/metadata-key contracts, host-driven membership grant/suspend/expire commands, invitation issue/accept/revoke/expire commands, store-failed persistence posture, tenancy.administration.workflow, diagnostics 4546-4547, the tenant-administration runtime surface, and base tenant-governance-boundaries truth for the companion-shipped lane while the ASP.NET Core command endpoint later shipped in ENG-255 and host-agnostic invitation delivery dispatch later shipped in ENG-256; tenant-admin UI, public onboarding, provider-specific invitation senders, identity-provider synchronization, distributed or provider-backed governance storage, and provider mutation remain outside this proof
the 2026-04-29 ENG-255 slice shipped the first host-adapter tenant-admin endpoint proof: Cephalon.MultiTenancy.Governance.AspNetCore now adds MapCephalonTenantAdministrationCommands(), the default POST /engine/tenant-administration/commands route, fail-closed authorization with optional policy configuration, configuration keys under Engine:MultiTenancy:Governance:AspNetCore, the tenant-administration-http-endpoints runtime surface, and focused hosting/tooling/reference-doc coverage while the host-agnostic invitation delivery dispatch lane later shipped in ENG-256; tenant-admin UI, public onboarding, provider-specific invitation senders, identity-provider synchronization, distributed/provider-backed governance storage, and provider mutation remain outside this proof
the 2026-04-29 ENG-256 slice shipped the twenty-first concrete governance companion proof: Cephalon.MultiTenancy.Governance now adds ITenantInvitationDeliveryDispatcher, ITenantInvitationDeliverySender, ITenantInvitationDeliveryRunCatalog, delivery request/result/run contracts, delivery metadata keys and outcome vocabulary, dispatch over registered sender extensions, sender-not-configured and sender-failed truth, bounded in-memory run history, optional persisted delivery metadata through ITenantInvitationStore, tenancy.invitation.delivery-dispatch, diagnostics 4548-4549, and tenant-invitations plus tenant-administration runtime metadata for dispatch enablement, sender count/ids, sender ownership, external-delivery ownership, latest outcome, and run counts without taking over provider-specific email/SMS/chat/identity-provider senders, public onboarding, tenant-admin UI, distributed/provider-backed governance storage, or provider mutation
the 2026-04-29 ENG-257 slice shipped the optional HTTP invitation delivery sender proof: Cephalon.MultiTenancy.Governance.HttpDelivery now adds HttpInvitationDeliveryOptions, AddCephalonHttpInvitationDelivery(...), HttpInvitationDeliveryPayload, a provider-managed http-webhook ITenantInvitationDeliverySender, bounded JSON webhook dispatch with configurable method/timeout/headers/accepted statuses/supported channels, provider-message id response-header capture, diagnostics 4550-4551, default reference-doc inclusion, and focused composition/tooling coverage over the existing governance dispatcher while provider-specific email/SMS/chat/CRM/identity-provider connectors, durable retry queues, provider-specific callback endpoints or provider polling, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation remain outside this proof
the 2026-04-29 ENG-258 slice shipped the HTTP invitation delivery webhook signing proof: Cephalon.MultiTenancy.Governance.HttpDelivery now adds SigningSecret, SigningKeyId, configurable signature/timestamp/key-id header names, HMAC-SHA256 signing over {unixTimestamp}.{jsonBody}, v1=<lowercase hex> signature emission, safe httpSigned and httpSigningKeyId sender metadata, and focused composition/reference-doc coverage while provider-specific email/SMS/chat/CRM/identity-provider connectors, durable retry queues, provider-specific delivery-status callback endpoints or provider polling, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation remain outside this proof
the 2026-04-29 ENG-259 slice shipped the HTTP invitation delivery retry proof: Cephalon.MultiTenancy.Governance.HttpDelivery now adds MaxAttempts, RetryDelayMilliseconds, RetryStatusCodes, RetryTransportFailures, fresh request construction per attempt, bounded in-process retry/backoff over configured transient status codes and transport failures, safe attempt/retry metadata such as httpAttemptCount, httpMaxAttempts, httpRetried, and httpRetryReason, plus focused composition/reference-doc coverage while durable retry queues, provider-specific delivery-status callback endpoints or provider polling, provider-specific invitation connectors, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation remain outside this proof
the 2026-04-29 ENG-260 slice shipped the HTTP invitation delivery idempotency proof: Cephalon.MultiTenancy.Governance.HttpDelivery now adds EnableIdempotencyHeader, IdempotencyHeaderName, IdempotencyMetadataKey, provider-neutral idempotency headers on every webhook attempt, caller-supplied header-safe dispatch metadata keys when present, deterministic hashing for overlong/header-unsafe metadata keys, derived hashed keys from tenant/invitation/channel/sender when absent, stable retry-attempt idempotency, and safe httpIdempotencyHeaderName, httpIdempotencyKey, and httpIdempotencyKeySource metadata while durable retry queues, provider-specific delivery-status callback endpoints or provider polling, provider-specific invitation connectors, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation remain outside this proof
the 2026-04-29 ENG-261 slice shipped the host-agnostic invitation delivery status reconciliation proof: Cephalon.MultiTenancy.Governance now adds ITenantInvitationDeliveryStatusReconciler, delivery status request/result contracts, status and reconciliation-outcome vocabularies, status metadata keys, provider-message id match guarding, tenancy.invitation.delivery-status-reconciliation, diagnostics 4552-4553, and tenant-invitations plus tenant-administration metadata for status reconciliation ownership, external status ownership, reported status count, latest status, and latest observed timestamp while provider-specific callback endpoints, provider polling, durable retry queues, provider-specific invitation connectors, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation remain outside this proof
the 2026-04-29 ENG-262 slice repaired behavior REST ownership truth: Cephalon.Behaviors.Http remains metadata-first for BehaviorRestProfileAttribute and BehaviorRestBindingAttribute, but explicit module-owned MapProfile<TBehavior>(), MapGeneratedProfiles(...), and grouped generated shorthand now publish stable runtime metadata through /engine/rest-endpoints, /engine/rest-endpoint-candidates, and snapshot.RestEndpoints: restPublicationActivationOwnership = application-managed, restMaterializationOwnership = cephalon-managed, restProfileMetadataOwnership = application-managed, and restPublicationActivationMode values such as explicit-map-profile or explicit-map-generated-profiles; the maturity audit should treat this as mixed M2, not metadata-only M1, while ambient behavior-to-REST auto-publication remains out of scope
the 2026-04-29 ENG-263 slice shipped the eventing subscription execution-binding catalog proof: Cephalon.Eventing now exposes IEventSubscriptionExecutionBindingCatalog plus stable EventSubscriptionRuntimeMetadataKeys so hosts and companion packs can read active managed subscription bindings directly by subscription id, while Cephalon.Eventing.Wolverine remains the optional provider-managed proof that contributes a wolverine-managed binding through the existing adapter-neutral contributor seam
the 2026-04-29 ENG-264 slice shipped the eventing subscription execution-readiness catalog proof: Cephalon.Eventing now derives runtime-bound, hosted-execution-linked, application-managed-state, and declared-only readiness from declared subscriptions, managed bindings, hosted-execution links, and application-managed runtime reports, and projects executionReadiness, executionPath, and executionReadinessReasons through the event-subscriptions technology surface without claiming generic broker or inbox ownership
the 2026-04-29 ENG-265 / issue #774 slice shipped the eventing subscription readiness operator surface: EventSubscriptionExecutionReadinessDescriptor, EventSubscriptionExecutionReadinessStates, and IEventSubscriptionExecutionReadinessCatalog now live in Cephalon.Abstractions.Data, Cephalon.Eventing remains the implementation owner, ASP.NET Core exposes /engine/event-subscription-readiness plus /engine/event-subscription-readiness/{subscriptionId}, and RuntimeIntrospectionSnapshot now carries EventSubscriptionExecutionReadiness so host adapters can publish readiness without depending on Cephalon.Eventing
the 2026-04-29 ENG-266 / issue #775 slice shipped the agentics tool-run operator surface: AgentToolExecutionOutcomes, AgentToolRunState, and IAgentToolRunCatalog now live in Cephalon.Abstractions.Agentics, Cephalon.Agentics remains the dispatcher/reporting implementation owner, ASP.NET Core exposes /engine/agent-tool-runs, /engine/agent-tool-runs/{runId}, and /engine/agent-tool-runs/by-tool/{toolId}, and RuntimeIntrospectionSnapshot now carries AgentToolRuns so host adapters can publish agent-tool run state without depending on Cephalon.Agentics
the 2026-04-29 ENG-267 / issue #776 slice shipped the retrieval knowledge-index operator surface: IKnowledgeIndexCatalog, KnowledgeIndexState, KnowledgeIndexFreshnessStates, and KnowledgeIndexingOutcomes now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval remains the document-provider ingestion, lexical indexing, bounded query, freshness, and in-memory index-state implementation owner, ASP.NET Core exposes /engine/knowledge-indexes plus /engine/knowledge-indexes/{collectionId}, and RuntimeIntrospectionSnapshot now carries KnowledgeIndexes so host adapters can publish index posture without depending on Cephalon.Retrieval
the 2026-04-29 ENG-268 / issue #777 slice shipped the retrieval reindex operator action surface: IKnowledgeIndexer, KnowledgeIndexingRequest, and KnowledgeIndexingResult now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval remains the provider-ingestion, lexical-indexing, freshness, and index-state implementation owner, ASP.NET Core exposes POST /engine/knowledge-indexes/{collectionId}/reindex, and route-triggered reindex runs record safe run id, actor, correlation, trigger, and route metadata while background scheduling was still future at that slice boundary; opt-in in-process scheduling later shipped in ENG-270, while durable/distributed indexes, vector search, distributed scheduler coordination, and provider-specific semantic search stay future package-owned work
the 2026-04-29 ENG-269 / issue #778 slice shipped the agentics tool execution operator action surface: IAgentToolDispatcher, AgentToolExecutionRequest, and AgentToolExecutionResult now live in Cephalon.Abstractions.Agentics, Cephalon.Agentics remains the descriptor-resolution, policy, executor, observer, reporter, and run-state implementation owner, ASP.NET Core exposes POST /engine/agent-tools/{toolId}/runs, and route-triggered tool runs record safe run id, actor, correlation, attempt, arguments, trigger, and route metadata while autonomous planning, memory persistence, durable retry queues, provider-specific AI orchestration, and broader agent operator workflows stay future package-owned work
the 2026-04-29 ENG-270 / issue #779 slice shipped the retrieval background reindex scheduler baseline: Cephalon.Retrieval now adds opt-in scheduler options, registers a generic-host IHostedService only when ingestion and background reindexing are enabled, runs startup and interval reindex attempts over all registered collections or configured collection ids through the existing IKnowledgeIndexer, records safe scheduler metadata, and surfaces retrieval.background-reindexing plus backgroundReindexing* metadata including per-collection scheduled/not-selected truth while durable/distributed indexes, vector search, provider-specific semantic search, distributed scheduler coordination, leader election, and multi-node freshness orchestration stay future package-owned work
the 2026-04-29 ENG-271 / issue #780 slice shipped the eventing in-process subscription execution baseline: Cephalon.Eventing now adds EnableInProcessSubscriptionExecution, registers a Cephalon-managed direct in-process publisher when matching IEventSubscriptionExecutor services exist, publishes eventing.publish and eventing.subscribe with cephalon-managed, in-process-direct, and retryPolicy = none truth, executes matching subscriptions through IEventPublisher, and projects the resulting runtime state through event-publishers, event-subscriptions, /engine/event-subscription-readiness, and snapshot.EventSubscriptionExecutionReadiness; durable broker dispatch, inbox/idempotency ownership, retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work
the 2026-04-29 ENG-272 / issue #781 slice shipped the eventing publication operator action baseline: publication command contracts now live in Cephalon.Abstractions.Data, Cephalon.Eventing registers a bounded IEventPublicationDispatcher over the active IEventPublisher when a publishing path exists, ASP.NET Core exposes POST /engine/event-publications, safe route metadata flows into publication results and in-process subscription execution state, and runtime surfaces mark publicationDispatcher = available; durable broker dispatch, inbox/idempotency ownership, retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work
the 2026-04-29 ENG-273 / issue #782 slice shipped the eventing in-process subscription retry baseline: Cephalon.Eventing now adds InProcessSubscriptionMaxAttempts and InProcessSubscriptionRetryDelayMilliseconds, preserves retryPolicy = none by default, retries transient direct executor failures inline when max attempts is greater than one, reports retry-scheduled plus final runtime state through IEventSubscriptionRuntimeCatalog, and projects bounded-in-process, max-attempt, delay, retryDurability = none, and retryScope = process-local metadata through capabilities, bindings, event-publishers, event-subscriptions, and reported.*; durable broker retries, inbox/idempotency ownership, durable retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work
the 2026-04-29 ENG-274 / issue #783 slice shipped the eventing in-process subscription idempotency baseline: Cephalon.Eventing now adds EnableInProcessSubscriptionIdempotency and InProcessSubscriptionIdempotencyRetentionMinutes, preserves current behavior by default, tracks successful direct subscriptionId + publicationId executions in bounded process-local memory when enabled, reports duplicate completed executions as skipped through IEventSubscriptionRuntimeCatalog, and projects idempotencyPolicy = completed-publication, idempotencyKey = subscription-publication, retention, idempotencyDurability = none, and idempotencyScope = process-local metadata through capabilities, bindings, event-publishers, event-subscriptions, and reported.*; durable inbox ownership, cross-node exactly-once delivery, broker deduplication, durable retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work
the 2026-04-29 ENG-275 / issue #784 slice shipped the eventing publication runtime operator-state baseline: EventPublicationRuntimeOutcomes, EventPublicationRuntimeState, and IEventPublicationRuntimeCatalog now live in Cephalon.Abstractions.Data, Cephalon.Eventing reports direct in-process publication succeeded/failed/skipped posture with subscription counters and safe metadata, outbox-backed publication reports accepted staged handoff with deliveryCompletion = pending-dispatch, ASP.NET Core exposes /engine/event-publications/runtime, /engine/event-publications/runtime/{publicationId}, and /engine/event-publications/runtime/channels/{channelId}, and RuntimeIntrospectionSnapshot carries EventPublicationStates; durable broker dispatch, downstream delivery completion, durable inbox ownership, cross-node exactly-once delivery, durable retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work
the 2026-04-29 ENG-276 / issue #785 slice shipped the Wolverine bounded subscription retry terminal-failure baseline: Cephalon.Eventing.Wolverine now adds SubscriptionMaxAttempts, reports retryPolicy = bounded-fixed-delay plus max-attempt, delay, durability, and provider-managed scope metadata through capabilities, binding metadata, event-subscriptions, and the wolverine-adapter runtime surface, continues using Wolverine scheduled messages while attempts remain, and reports terminal failed state with retryExhausted = true / terminalFailure = true when the retry budget is exhausted; generic inbound broker-consumption ownership, durable inbox ownership, and dispatch-loop dead-letter or terminal-failure storage semantics remain future package-owned work
the 2026-04-29 ENG-277 / issue #786 slice shipped the Wolverine dispatch terminal retry-failure baseline: Cephalon.Eventing.Wolverine now adds DispatchMaxAttempts, reports retryPolicy = bounded-fixed-delay 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 retryOutcome = max-attempts-exhausted, retryExhausted = true, and terminalFailure = true when no-destination or publish failures exhaust the retry budget; supported dispatch stores now use EventDispatchRuntimeMetadataKeys to stop terminal failed staged publications from re-entering pending reads, while broker-specific dead-letter queues, durable inbox ownership, cross-node exactly-once delivery, and generic inbound broker-consumption remain future package-owned work
the 2026-04-29 ENG-278 / issue #787 slice tightened that Wolverine dispatch terminal proof around real publish exceptions: focused composition coverage now proves that a PublishAsync(...) exception with destinations present reports retryable retry-scheduled metadata before the budget is exhausted, reports terminal failed metadata with routing = publish, exceptionType, retryOutcome = max-attempts-exhausted, retryExhausted = true, and terminalFailure = true on the final attempt, and removes the staged publication from pending-dispatch reads through the same terminal metadata contract; broker-specific dead-letter queues, durable inbox ownership, generic inbound broker consumption, and cross-node exactly-once delivery remain future package-owned work
the 2026-04-29 ENG-279 / issue #788 slice promoted terminal event-dispatch failure posture from metadata-only to first-class operator truth: EventDispatchRuntimeState now exposes TerminalFailure plus TerminalFailureCount, EventDispatchRuntimeSummary now exposes TerminalFailureCount, TerminalOutboxCount, and HasTerminalFailures, ASP.NET Core now exposes /engine/event-dispatches/terminal-failures, and the event-dispatch technology surfaces plus snapshot.EventDispatch* carry the same typed posture; this is still dispatch-report/dispatch-store truth, not broker-specific dead-letter, durable inbox, generic inbound broker-consumption, downstream delivery-completion, or cross-node exactly-once ownership
the 2026-04-29 ENG-280 / issue #789 slice added bounded process-local retry posture to the Agentics dispatcher lane: AgenticRuntimeOptions now exposes ExecutionMaxAttempts plus ExecutionRetryDelayMilliseconds, the dispatcher reports retry-scheduled observations before retrying failed executor attempts, AgentToolRunState exposes RetryScheduledCount and RetryPending, ASP.NET Core exposes /engine/agent-tool-runs/retry-pending, and agentics.execution plus agent-tools metadata publish retry policy, max attempts, delay, durability, scope, counters, and pending posture while durable retry queues, autonomous planning, memory persistence, distributed scheduling, and provider-specific AI orchestration remain future package-owned work
the 2026-04-29 ENG-281 / issue #790 slice added opt-in bounded process-local duplicate-completed idempotency posture to the Agentics dispatcher lane: AgenticRuntimeOptions now exposes EnableExecutionIdempotency plus ExecutionIdempotencyRetentionMinutes, duplicate completed toolId + runId executions are reported as skipped without invoking the executor again, AgentToolRunState exposes DuplicateCompleted, ASP.NET Core exposes /engine/agent-tool-runs/idempotency-duplicates, and agentics.execution plus agent-tools metadata publish idempotency policy, key, retention, durability, scope, counters, and duplicate posture while durable inboxes, cross-node exactly-once delivery, durable retry queues, autonomous planning, memory persistence, distributed scheduling, and provider-specific AI orchestration remain future package-owned work
the 2026-04-29 ENG-282 / issue #791 slice added approval-required and terminal-failure operator posture to the Agentics dispatcher lane: AgentToolRunState now exposes TerminalFailure, ASP.NET Core exposes /engine/agent-tool-runs/approval-required plus /engine/agent-tool-runs/terminal-failures, and the agent-tools runtime surface publishes terminalFailure metadata so operators can separate policy-blocked runs from terminal failed executor outcomes while durable approval workflows, dead-letter systems, durable retry queues, durable inboxes, cross-node exactly-once delivery, autonomous planning, memory persistence, distributed scheduling, and provider-specific AI orchestration remain future package-owned work
the 2026-04-29 ENG-283 / issue #792 slice added the retrieval query operator action seam: IKnowledgeQueryEngine, KnowledgeQueryRequest, KnowledgeQueryResult, and KnowledgeQueryMatch now live in Cephalon.Abstractions.Retrieval, Cephalon.Retrieval remains the bounded lexical query implementation and runtime-observation owner, ASP.NET Core exposes POST /engine/knowledge-indexes/{collectionId}/queries, and route-triggered queries record safe actor, correlation, trigger, route, metadata, query fingerprint, query length, and match-count posture while vector databases, embeddings, durable/distributed indexes, rerankers, semantic provider adapters, distributed scheduler coordination, and leader election remain future package-owned work
the 2026-04-29 ENG-284 / issue #793 slice added the multi-tenancy invitation delivery status callback endpoint baseline: Cephalon.MultiTenancy.Governance.AspNetCore now exposes TenantInvitationDeliveryStatusCallbackRequest plus MapCephalonTenantInvitationDeliveryStatusCallbacks() for POST /engine/tenant-invitations/delivery-status, keeps callback authorization fail-closed by default, enforces provider-message matching by default, records safe callback-ingress metadata before calling ITenantInvitationDeliveryStatusReconciler, and projects tenant-invitation-delivery-status-http-endpoints with route, authorization, provider-message-match, and provider-specific translation/signature/polling boundary truth while provider-specific callback payload translation, provider-specific callback signature verification, provider polling, durable notification queues, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-285 / issue #800 slice added provider-neutral callback signature verification for that ASP.NET Core normalized delivery-status ingress: when TenantInvitationDeliveryStatusCallbackSigningSecret is configured, MapCephalonTenantInvitationDeliveryStatusCallbacks() verifies v1=<hex-hmac-sha256> over {unixTimestamp}.{exactUtf8JsonBody} before JSON parsing or reconciliation, supports configurable signature/timestamp/key-id headers plus timestamp tolerance, records safe verified-signature metadata, and projects signature verification posture through tenant-invitation-delivery-status-http-endpoints while provider-specific callback payload translation, provider-specific signature semantics, provider polling, durable notification queues, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-286 / issue #801 slice added bounded process-local replay protection for signed ASP.NET Core normalized delivery-status callbacks: when TenantInvitationDeliveryStatusCallbackSigningSecret is configured and EnableTenantInvitationDeliveryStatusCallbackReplayProtection remains enabled, MapCephalonTenantInvitationDeliveryStatusCallbacks() records safe SHA-256 signature fingerprints for accepted signed callbacks, rejects duplicate signed requests with 409 inside TenantInvitationDeliveryStatusCallbackReplayRetentionSeconds, projects replay policy/key/scope/durability/retention/cache-limit posture through tenant-invitation-delivery-status-http-endpoints, and remains explicit that provider-specific or distributed callback inboxes, cross-node replay protection, provider-specific callback payload translation/signature semantics, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores are still future package-owned work
the 2026-04-29 ENG-287 / issue #802 slice added the host-agnostic invitation delivery status observation store baseline: Cephalon.MultiTenancy.Governance now adds ITenantInvitationDeliveryStatusObservationStore, TenantInvitationDeliveryStatusObservationDescriptor, an in-memory default store, opt-in local JSON durability through MultiTenancyGovernanceOptions.InvitationDeliveryStatusObservationStoreFilePath, retention through InvitationDeliveryStatusObservationHistoryLimit, the tenancy.invitation.delivery-status-observation-store capability, and tenant-invitations metadata for observation-store kind, durability, scope, history limit, count, and latest observation while staying explicit that provider-specific or distributed callback inboxes, cross-node replay protection, provider-specific callback payload translation/signature semantics, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores are still future package-owned work
the 2026-04-29 ENG-288 / issue #803 slice added the ASP.NET Core invitation delivery status observation endpoint baseline: Cephalon.MultiTenancy.Governance.AspNetCore now exposes MapCephalonTenantInvitationDeliveryStatusObservations() for bounded/filterable GET /engine/tenant-invitations/delivery-status/observations reads over ITenantInvitationDeliveryStatusObservationStore, returns TenantInvitationDeliveryStatusObservationQueryResult, keeps observation reads fail-closed by default through RequireTenantInvitationDeliveryStatusObservationAuthorization, reports route/auth/limit/read-contract posture through tenant-invitation-delivery-status-http-endpoints, and stays explicit that provider-specific callback inboxes, provider polling, distributed replay ledgers, exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores are still future package-owned work
the 2026-04-29 ENG-289 / issue #804 slice added the ASP.NET Core invitation delivery dispatch endpoint baseline: Cephalon.MultiTenancy.Governance.AspNetCore now exposes MapCephalonTenantInvitationDeliveryDispatches() for fail-closed POST /engine/tenant-invitations/delivery-dispatches actions over ITenantInvitationDeliveryDispatcher, defaults the dispatch source to aspnetcore-invitation-delivery-dispatch, records safe adapter metadata, maps dispatcher outcomes to explicit HTTP statuses, and reports route/auth/status-mapping/boundary posture through tenant-invitation-delivery-http-endpoints while provider-specific senders, distributed retry queues, public onboarding, tenant-admin UI/backoffice, identity-provider sync, provider polling, callback inboxes, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-290 / issue #805 slice added the host-agnostic invitation delivery retry queue baseline: Cephalon.MultiTenancy.Governance now exposes ITenantInvitationDeliveryRetryStore, ITenantInvitationDeliveryRetryRunner, retry descriptor/request/result contracts, retry statuses/outcomes, retry metadata keys, opt-in EnableInvitationDeliveryRetryQueue, local JSON durability through InvitationDeliveryRetryQueueFilePath, bounded manual RetryPendingAsync(...) replay over retryable sender-failed outcomes, tenancy.invitation.delivery-retry-queue, and tenant-invitations retry queue ownership/kind/durability/count/latest posture while distributed retry queues, cross-node leases, exactly-once delivery, provider-specific senders, public onboarding, tenant-admin UI/backoffice, identity-provider sync, provider polling, callback inboxes, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-291 / issue #806 slice added opt-in automatic invitation delivery retry background scheduling: Cephalon.MultiTenancy.Governance now exposes EnableInvitationDeliveryRetryBackgroundScheduling, InvitationDeliveryRetryBackgroundIntervalSeconds, InvitationDeliveryRetryBackgroundRunOnStartup, InvitationDeliveryRetryBackgroundSource, TenantInvitationDeliveryRetryHostedService, ITenantInvitationDeliveryRetryRuntimeCatalog, TenantInvitationDeliveryRetryRuntimeSnapshot, tenancy.invitation.delivery-retry-background-scheduling, diagnostics 4554-4557, and tenant-invitations deliveryRetryBackground* metadata while distributed retry queues, cross-node leases, exactly-once delivery, provider-specific senders, public onboarding, tenant-admin UI/backoffice, identity-provider sync, provider polling, callback inboxes, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-292 / issue #807 slice added process-local invitation delivery retry execution coordination: Cephalon.MultiTenancy.Governance now exposes EnableInvitationDeliveryRetryExecutionCoordination, ITenantInvitationDeliveryRetryExecutionCoordinationCatalog, TenantInvitationDeliveryRetryExecutionCoordinationSnapshot, the already-running retry outcome, stable coordination metadata keys, tenancy.invitation.delivery-retry-execution-coordination, and tenant-invitations deliveryRetryExecutionCoordination* metadata; overlapping retry runner passes inside one host process now skip without dispatching entries or mutating the retry queue while distributed retry queues, cross-node leases, exactly-once delivery, provider-specific senders, public onboarding, tenant-admin UI/backoffice, identity-provider sync, provider polling, callback inboxes, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-293 / issue #808 slice added the optional SMTP invitation delivery sender proof: Cephalon.MultiTenancy.Governance.SmtpDelivery now exposes SmtpInvitationDeliveryOptions, AddCephalonSmtpInvitationDelivery(...), ISmtpInvitationDeliveryClient, SmtpInvitationDeliveryMessage, and SmtpInvitationDeliveryClientResult; it registers the default smtp-email ITenantInvitationDeliverySender, resolves recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, prepares templated plain-text/HTML messages, derives deterministic SMTP Message-Id values, records safe relay/recipient/message metadata, emits diagnostics 4558-4559, and stays explicit that provider-specific email APIs, SMS/chat/CRM/identity-provider senders, bounce/callback translation, provider polling, distributed retry queues, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-29 ENG-294 / issue #809 slice added the optional SendGrid invitation delivery sender proof: Cephalon.MultiTenancy.Governance.SendGridDelivery now exposes SendGridInvitationDeliveryOptions, AddCephalonSendGridInvitationDelivery(...), ISendGridInvitationDeliveryClient, SendGridInvitationDeliveryMessage, and SendGridInvitationDeliveryClientResult; it registers the default sendgrid-email ITenantInvitationDeliverySender, posts templated Mail Send API payloads to /v3/mail/send, resolves recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, carries deterministic Cephalon message ids through safe custom arguments and headers, supports SendGrid sandbox validation where 200 OK is accepted alongside the normal 202 Accepted, captures X-Message-ID as the provider message id, records only safe endpoint/status/sandbox/category/custom-argument/recipient metadata, emits diagnostics 4560-4561, and stays explicit that SendGrid Event Webhook translation, webhook signature verification, bounce handling, provider polling, dynamic-template lifecycle management, Mailgun handoff later shipped through ENG-299, Amazon SES v2 handoff later shipped through ENG-306, additional non-SendGrid email APIs beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, distributed retry queues, public onboarding, tenant-admin UI/backoffice, identity-provider sync, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-295 / issue #810 slice added the optional SendGrid Event Webhook callback translation proof: Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore now exposes SendGridInvitationDeliveryAspNetCoreOptions, AddCephalonSendGridInvitationDeliveryAspNetCore(...), MapCephalonSendGridInvitationDeliveryStatusCallbacks(), SendGridInvitationDeliveryStatusCallbackResult, and SendGridInvitationDeliveryStatusCallbackEventResult; it maps fail-closed POST /engine/tenant-invitations/delivery-status/sendgrid, parses bounded SendGrid JSON event arrays, extracts Cephalon custom arguments, normalizes sg_message_id to the stored SendGrid X-Message-ID provider message id by default, translates processed/delivered/deferred/bounce/suppression events into normalized delivery statuses, skips engagement events by default, records safe status metadata and sendgrid:{sg_event_id} observation ids, emits diagnostics 4562, and projects tenant-invitation-delivery-sendgrid-status-callbacks; at that point, 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/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remained future package-owned work
the 2026-04-30 ENG-296 / issue #811 slice added optional SendGrid signed Event Webhook verification to Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore: when RequireSignedEventWebhook is enabled, MapCephalonSendGridInvitationDeliveryStatusCallbacks() verifies X-Twilio-Email-Event-Webhook-Signature and X-Twilio-Email-Event-Webhook-Timestamp with ECDSA-SHA256 over timestamp + rawBody before JSON parsing or reconciliation, rejects invalid signed callbacks before touching invitation state or delivery-status observations, records safe signature metadata and callback-result posture, emits diagnostics 4563, and projects signature verification as cephalon-managed through tenant-invitation-delivery-sendgrid-status-callbacks while durable callback inboxes, distributed replay protection, provider polling, non-SendGrid callback translation/signature semantics, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-297 / issue #812 slice added bounded process-local replay protection for verified SendGrid signed Event Webhook callbacks: when RequireSignedEventWebhook and EnableSignedEventWebhookReplayProtection are enabled, MapCephalonSendGridInvitationDeliveryStatusCallbacks() records safe SHA-256 signature fingerprints in a bounded in-memory cache, rejects duplicate verified signatures with 409 before reconciliation, records safe replay metadata and callback-result posture, emits diagnostics 4564, and projects replay policy/key/scope/durability/retention/cache posture through tenant-invitation-delivery-sendgrid-status-callbacks while durable callback 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, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-298 / issue #813 slice added observation-store-backed SendGrid event-id idempotency to Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore: when EnableEventWebhookEventIdIdempotency is enabled, MapCephalonSendGridInvitationDeliveryStatusCallbacks() checks the normalized sendgrid:{sg_event_id} observation id in ITenantInvitationDeliveryStatusObservationStore, skips duplicate translated events before invoking the reconciler, returns DuplicateEvents plus per-event duplicate-skipped outcomes, records safe idempotency metadata, emits diagnostics 4565, and projects event-id idempotency posture through tenant-invitation-delivery-sendgrid-status-callbacks while 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, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-299 / issue #814 slice added the optional Mailgun invitation delivery sender proof: Cephalon.MultiTenancy.Governance.MailgunDelivery now exposes MailgunInvitationDeliveryOptions, AddCephalonMailgunInvitationDelivery(...), IMailgunInvitationDeliveryClient, MailgunInvitationDeliveryMessage, and MailgunInvitationDeliveryClientResult; it registers the default mailgun-email ITenantInvitationDeliverySender, posts templated multipart Messages API payloads to /v3/{domain}/messages, resolves recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, carries deterministic Cephalon message ids through safe v:* variables and h:* headers, supports Mailgun test mode through o:testmode=yes, captures the JSON id response as the provider message id, records only safe endpoint/status/domain/test-mode/tag/variable/header/recipient metadata, emits diagnostics 4566-4567, and stays explicit that Mailgun webhook 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, Mailgun event-id idempotency later shipped through ENG-303, Microsoft Graph sendMail handoff later shipped through ENG-304, and Amazon SES v2 handoff later shipped through ENG-306, while additional provider senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, provider polling, durable callback inboxes, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-300 / issue #815 slice added the optional Mailgun webhook callback translation proof: Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore now exposes MailgunInvitationDeliveryAspNetCoreOptions, AddCephalonMailgunInvitationDeliveryAspNetCore(...), MapCephalonMailgunInvitationDeliveryStatusCallbacks(), MailgunInvitationDeliveryStatusCallbackResult, and MailgunInvitationDeliveryStatusCallbackEventResult; it maps fail-closed POST /engine/tenant-invitations/delivery-status/mailgun, parses bounded Mailgun JSON event objects plus bounded arrays for controlled replay/tests, extracts Cephalon user-variables, normalizes message.headers.message-id with angle brackets by default to match the sender’s captured Mailgun JSON id, translates Mailgun delivery events into normalized delivery statuses, skips engagement events by default, records safe status metadata and mailgun:{id} observation ids, emits diagnostics 4568, and projects tenant-invitation-delivery-mailgun-status-callbacks; 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, while durable callback inboxes, distributed replay/event-id ledgers, provider polling, cross-node exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-301 / issue #816 slice added optional Mailgun signed webhook verification to Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore: when RequireSignedWebhook is enabled, MapCephalonMailgunInvitationDeliveryStatusCallbacks() verifies the Mailgun HMAC-SHA256 hex digest over timestamp + token using WebhookSigningKey, accepts signature.parent-signature for subaccount events when AcceptParentSignature is enabled, rejects missing/malformed/stale/invalid signed callbacks before reconciliation, records safe signature metadata and callback-result posture, emits diagnostics 4569, and projects signature verification as cephalon-managed through tenant-invitation-delivery-mailgun-status-callbacks; Mailgun replay-token rejection later shipped through ENG-302 and Mailgun event-id idempotency later shipped through ENG-303, while durable callback inboxes, distributed replay/event-id ledgers, provider polling, cross-node exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-302 / issue #817 slice added bounded process-local Mailgun signed webhook replay protection to Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore: when RequireSignedWebhook and EnableSignedWebhookReplayProtection are enabled, verified Mailgun webhook tokens are retained as SHA-256 fingerprints for SignedWebhookReplayRetentionSeconds up to SignedWebhookReplayCacheLimit, duplicate tokens return 409 before reconciliation, accepted callbacks record safe replay metadata and callback-result posture, diagnostics now include 4570, and tenant-invitation-delivery-mailgun-status-callbacks reports replay ownership as cephalon-managed, policy signed-webhook-token, key token-fingerprint, scope process-local, and durability none; durable callback inboxes, distributed replay/event-id ledgers, provider polling, cross-node exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-303 / issue #818 slice added observation-store-backed Mailgun event-id idempotency to Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore: when EnableWebhookEventIdIdempotency is enabled and the governance observation store is enabled, MapCephalonMailgunInvitationDeliveryStatusCallbacks() checks the normalized mailgun:{event-data.id} observation id in ITenantInvitationDeliveryStatusObservationStore, skips duplicate translated events before invoking the reconciler, returns DuplicateEvents plus per-event duplicate-skipped outcomes, records safe idempotency metadata, emits diagnostics 4571, and projects event-id idempotency posture through tenant-invitation-delivery-mailgun-status-callbacks while durable callback inboxes, distributed replay/event-id ledgers, provider polling, cross-node exactly-once delivery, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-304 / issue #819 slice added the optional Microsoft Graph invitation delivery sender proof: Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery now exposes MicrosoftGraphInvitationDeliveryOptions, AddCephalonMicrosoftGraphInvitationDelivery(...), IMicrosoftGraphInvitationDeliveryClient, IMicrosoftGraphInvitationDeliveryAccessTokenProvider, MicrosoftGraphInvitationDeliveryMessage, and MicrosoftGraphInvitationDeliveryClientResult; it registers the default microsoft-graph-email ITenantInvitationDeliverySender, posts templated JSON payloads to Graph sendMail, resolves recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, carries deterministic Cephalon message ids through safe custom x-* internet message headers, records only safe Graph endpoint/status/request-id/category/header/recipient metadata, emits diagnostics 4572-4573, and stays explicit that Microsoft Entra app registration, permission consent, mailbox access policy, token-provider implementation before ENG-305, delivery completion after accepted handoff, Graph change notifications, provider polling, durable callback inboxes, Amazon SES v2 handoff later shipped through ENG-306, additional provider senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-305 / issue #820 slice added the optional Microsoft Graph Azure Identity token-provider proof: Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery.AzureIdentity now exposes MicrosoftGraphInvitationDeliveryAzureIdentityOptions and AddCephalonMicrosoftGraphInvitationDeliveryAzureIdentity(...); it replaces the Graph sender IMicrosoftGraphInvitationDeliveryAccessTokenProvider with Azure Identity-backed access-token acquisition, supports configuration/code-first DefaultAzureCredential setup, explicit TokenCredential injection, Graph scope selection, tenant id, managed-identity client id, authority-host selection, and safe credential exclusion toggles, emits diagnostics 4574-4575, never records token values or authorization headers, and stays explicit that Microsoft Entra app registration, Graph Mail.Send permission consent, mailbox access policy, credential lifecycle policy beyond the selected Azure credential, delivery completion after accepted handoff, Graph change notifications, provider polling, durable callback inboxes, Amazon SES v2 handoff later shipped through ENG-306, additional provider senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-306 / issue #821 slice added the optional Amazon SES v2 invitation delivery sender proof: Cephalon.MultiTenancy.Governance.AmazonSesDelivery now exposes AmazonSesInvitationDeliveryOptions, AddCephalonAmazonSesInvitationDelivery(...), IAmazonSesInvitationDeliveryClient, AmazonSesInvitationDeliveryMessage, and AmazonSesInvitationDeliveryClientResult; it registers the default amazon-ses-email ITenantInvitationDeliverySender, sends templated SES v2 SendEmail payloads, resolves recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, supports region/configuration-set/reply-to/tag configuration, captures SES MessageId as the provider message id, records only safe region/configuration-set/status/message-id/tag/recipient metadata, emits diagnostics 4576-4577, and stays explicit that AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox exit, Amazon SES over SNS callback translation later shipped through ENG-307, provider polling, durable callback inboxes, additional provider senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-307 / issue #822 slice added the optional Amazon SES over SNS callback translation proof: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now exposes AmazonSesInvitationDeliveryAspNetCoreOptions, AddCephalonAmazonSesInvitationDeliveryAspNetCore(...), MapCephalonAmazonSesInvitationDeliveryStatusCallbacks(), AmazonSesInvitationDeliveryStatusCallbackResult, and AmazonSesInvitationDeliveryStatusCallbackEventResult; it maps fail-closed POST /engine/tenant-invitations/delivery-status/amazon-ses, parses bounded SNS Notification envelopes, unwraps SES event publishing JSON from Message, extracts Cephalon context tags from mail.tags, correlates mail.messageId with the SES sender provider message id, translates SES delivery events into normalized delivery statuses, skips SNS confirmation/unsubscribe messages and engagement events by default, records safe callback metadata, emits diagnostics 4578, and projects tenant-invitation-delivery-amazon-ses-status-callbacks while SNS signature verification later shipped through ENG-308, process-local SNS replay protection through ENG-309, observation-store-backed SNS message-id idempotency through ENG-310, verified SNS subscription confirmation through ENG-311, and verified SNS unsubscribe-confirmation observation through ENG-312; SES event-destination setup, provider polling, durable callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-308 / issue #823 slice added optional Amazon SNS signature verification before Amazon SES callback translation: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now exposes RequireSnsSignatureVerification, RequireSnsSignatureVersion2, RequireAllowedSnsTopicArn, AllowedSnsTopicArns, PinnedSnsSigningCertificatePem, and ValidateSnsSigningCertificateChain; it rejects unsigned or invalid SNS envelopes before mapping/reconciliation, verifies SNS Notification, SubscriptionConfirmation, and UnsubscribeConfirmation canonical strings with RSA, requires signature version 2 and allowed TopicArn values by default, validates HTTPS Amazon SNS signing-certificate URLs, supports pinned PEM certificates for controlled tests, records safe signature metadata, emits diagnostics 4579, and projects signature-version/topic/certificate policy through tenant-invitation-delivery-amazon-ses-status-callbacks while SNS replay protection later shipped through ENG-309, observation-store-backed SNS message-id idempotency through ENG-310, verified SNS subscription confirmation through ENG-311, and verified SNS unsubscribe-confirmation observation through ENG-312; SES event-destination setup, provider polling, durable callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-309 / issue #824 slice added bounded process-local Amazon SNS replay protection before Amazon SES callback reconciliation: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now exposes EnableSnsReplayProtection, SnsReplayRetentionSeconds, and SnsReplayCacheLimit; when SNS signature verification is required and verified, it stores safe fingerprints derived from SNS TopicArn plus MessageId, rejects duplicate verified callbacks with 409 Conflict, 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 observation-store-backed SNS message-id idempotency later shipped through ENG-310, verified SNS subscription confirmation through ENG-311, and verified SNS unsubscribe-confirmation observation through ENG-312; SES event-destination setup, provider polling, durable callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-310 / issue #825 slice added observation-store-backed Amazon SNS message-id idempotency before Amazon SES callback reconciliation: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now exposes EnableSnsMessageIdIdempotency; when the governance observation store is enabled, it checks normalized amazon-ses-sns:{MessageId} observation ids before invoking the reconciler, skips duplicate translated SNS 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 later shipped through ENG-311 and verified SNS unsubscribe-confirmation observation later shipped through ENG-312; SES event-destination setup, provider polling, durable callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-311 / issue #826 slice added opt-in verified Amazon SNS subscription confirmation before Amazon SES callback translation/reconciliation: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now exposes EnableSnsSubscriptionConfirmation, SnsSubscriptionConfirmationTimeoutSeconds, IAmazonSesSnsSubscriptionConfirmationClient, AmazonSesSnsSubscriptionConfirmationRequest, and AmazonSesSnsSubscriptionConfirmationResult; it confirms only verified SubscriptionConfirmation envelopes from allowed topics, validates trusted HTTPS Amazon SNS SubscribeURL values, uses a bounded no-redirect default HTTP confirmation client, 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, and SNS topic/subscription creation, SES event-destination setup, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-312 / issue #827 slice added opt-in verified Amazon SNS unsubscribe-confirmation observation for Amazon SES callbacks: Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore now exposes EnableSnsUnsubscribeConfirmationObservation; when enabled with SNS signature verification, it observes only verified UnsubscribeConfirmation envelopes from allowed topics, validates required lifecycle fields and trusted HTTPS Amazon SNS SubscribeURL values, records safe observe-only metadata, reuses bounded process-local replay posture, returns unsubscribe-confirmation aggregate fields on AmazonSesInvitationDeliveryStatusCallbackResult, emits diagnostic 4584, and projects unsubscribe-confirmation ownership/action/SubscribeURL policy through tenant-invitation-delivery-amazon-ses-status-callbacks while never invoking SubscribeURL because that would re-confirm or restore the subscription; SNS topic/subscription creation, SES event-destination setup, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider sync, distributed retry queues, and distributed/provider-backed governance stores remain future package-owned work
the 2026-04-30 ENG-313 / issue #828 slice added filtered delivery-status observation rollup summaries to Cephalon.MultiTenancy.Governance.AspNetCore: TenantInvitationDeliveryStatusObservationQueryResult now exposes SummaryCount and Summaries, TenantInvitationDeliveryStatusObservationSummaryDescriptor reports dimension/value counts plus reconciled/recorded/latest timestamps, GET /engine/tenant-invitations/delivery-status/observations summarizes matched normalized observations by status, outcome, source, channel, sender, and tenant before applying the response record limit, and tenant-invitation-delivery-status-http-endpoints reports observation-summary ownership/scope/dimensions; this remains an operator/audit projection over the existing observation store, not a provider-specific callback inbox, provider polling loop, distributed replay/event-id ledger, or exactly-once delivery claim
the 2026-04-30 ENG-314 / issue #829 slice added delivery-status observation attention drill-downs to Cephalon.MultiTenancy.Governance.AspNetCore: TenantInvitationDeliveryStatusObservationAttentionCategories now exposes stable delivery-failed, delivery-deferred, delivery-suppressed, delivery-unknown, reconciliation-gap, and recording-gap labels, GET /engine/tenant-invitations/delivery-status/observations now includes an attention summary dimension derived from the matched normalized observation set before applying the response record limit, supports the attention= query filter, and reports observation-attention ownership/scope/categories through tenant-invitation-delivery-status-http-endpoints; this remains an operator/audit projection over the existing observation store, not a provider-specific callback inbox, provider polling loop, distributed replay/event-id ledger, or exactly-once delivery claim
the 2026-04-30 ENG-315 / issue #830 slice added delivery-status observation remediation hints to Cephalon.MultiTenancy.Governance.AspNetCore: TenantInvitationDeliveryStatusObservationRemediationActions now exposes stable action labels, TenantInvitationDeliveryStatusObservationRemediationHintDescriptor describes aggregate operator guidance, TenantInvitationDeliveryStatusObservationQueryResult now exposes RemediationHintCount and RemediationHints, GET /engine/tenant-invitations/delivery-status/observations derives hints from the matched normalized observation set before applying the response record limit, and tenant-invitation-delivery-status-http-endpoints reports remediation-hint ownership/scope/actions; this remains deterministic operator guidance over existing observation history, not provider polling, distributed remediation execution, distributed callback inbox, distributed replay/event-id ledger, or exactly-once delivery
the 2026-04-30 ENG-316 / issue #831 slice added delivery-status observation remediation-action filtering to Cephalon.MultiTenancy.Governance.AspNetCore: GET /engine/tenant-invitations/delivery-status/observations now includes a remediation summary dimension derived from matched normalized observations before applying the response record limit, supports the normalized remediation= query filter using the same stable action labels as remediation hints, and reports observation-remediation filter ownership/scope through tenant-invitation-delivery-status-http-endpoints; this remains an operator/audit projection over stored observations, not provider polling, distributed remediation execution, distributed callback inbox, distributed replay/event-id ledger, or exactly-once delivery
the 2026-04-30 ENG-317 / issue #832 slice added delivery-status observation provider-message drill-down filtering to Cephalon.MultiTenancy.Governance.AspNetCore: GET /engine/tenant-invitations/delivery-status/observations now includes a providerMessageId summary dimension derived from matched normalized observations before applying the response record limit, supports the providerMessageId= query filter for provider callback tracebacks, and reports observation-provider-message filter ownership/scope through tenant-invitation-delivery-status-http-endpoints; this remains an operator/audit projection over stored observations, not provider polling, provider-specific callback inbox, distributed remediation execution, distributed replay/event-id ledger, or exactly-once delivery
likely next phase-13 follow-through after the shared coverage, remediation, governance, drift, action-planning, write-path-readiness, preflight, dry-run, execution-intent, execution-approval, command-envelope, command-issuance, provider execution-adapter, execution outcome/history, retry/idempotency, retry-execution-policy, bounded command-journal, automatic background retry execution, automatic background retry coordination, durable command-journal, distributed retry lease, distributed retry orchestration, richer cross-node idempotency hardening, broader multi-node lease-execution, durable shared scheduler-orchestration, scheduler recovery/execution-hardening, broader provider-owned write-path execution, broader provider execution orchestration hardening, provider-owned control-plane ownership, provider-owned control-plane mutation/reconcile, provider-owned control-plane provisioning, provider-owned control-plane apply-and-reconcile execution, provider-owned control-plane dependency-aware apply-and-reconcile hardening, provider-owned control-plane dependency-aware provisioning and mutation hardening, provider-specific control-plane materializer, provider-specific control-plane dependency-aware teardown and mutation-execution hardening, provider-specific identity drill-down, provider-specific worker identity normalization, provider-specific worker drill-down, provider-specific transport drill-down, provider-specific dependency-identity drill-down, and provider-specific current-node drill-down follow-through baselines is later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through, while full Kafka Connect control-plane ownership still remains later than the shipped shared bounded retry plus durability plus lease plus orchestration plus hardening plus lease-execution plus scheduler plus recovery plus provider-owned write-path plus provider execution orchestration plus provider-owned control-plane ownership plus provider-owned control-plane mutation/reconcile plus provider-owned control-plane provisioning plus provider-owned control-plane apply-and-reconcile execution plus dependency-aware apply-and-reconcile hardening plus dependency-aware provisioning and mutation hardening plus provider-specific control-plane materializer plus provider-specific teardown and mutation-execution hardening plus provider-specific identity drill-down plus worker plus transport plus dependency-identity plus current-node operator truth
the 2026-04-19 repo-truth audit confirmed the remaining historically open pre-ENG-058-T78 REST cards (#324, #325, #326, #327, #329, #331, #337, #338, #339, #340, #341, and #342) were GitHub tracking drift rather than missing implementation work: the shipped backlog/roadmap/docs already describe those slices, focused validation passed through BehaviorRestRuntimeCatalogHostingTests (122/122) plus tooling/reference-doc suites (178/178), and GitHub project state should stay aligned with the repo-owned closeout posture instead of reopening those older REST baselines
the 2026-04-19 ENG-112 slice shipped the first durable live runtime-state and failure-posture baseline: active durable streams now surface through IDurableExecutionRuntimeStateCatalog, /engine/durable-executions/runtime, and snapshot.DurableExecutionStates with per-stream outcome, stage, replayed-version, known-version, append-count, output/completion posture, error summary, and contextual metadata derived from the shared durable strategy
the 2026-04-19 ENG-113 slice shipped the first durable timer/signal coordination baseline: DurableExecutionStepResult<TOutput> and DurableExecutionRuntimeState now carry pending timers/signals, the shared strategy now emits a waiting posture with 202 for coordination-only waits, and operators can filter active durable streams through /engine/durable-executions/runtime/timers* and /engine/durable-executions/runtime/signals*
the 2026-04-19 ENG-114 slice shipped the first durable compensation-helper baseline: DurableExecutionCompensationAction, DurableExecutionStepResult<TOutput>.CompensationActions, DurableExecutionRuntimeState.CompensationActions, and /engine/durable-executions/runtime/compensations* now keep operator-facing recovery guidance on the same shared durable runtime-state catalog without changing durable coordination semantics
the 2026-04-19 ENG-115 slice shipped the first higher-level saga choreography authoring-helper baseline: ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, SagaChoreographyStepResult<TOutput>, and typed JSON helper factories on SagaChoreographyPublication now keep lower-ceremony choreography authoring on the same shared execution contract without changing the explicit eventing bridge or introducing a second choreography registry
the 2026-04-19 ENG-116 slice shipped the first choreography runtime/operator catalog baseline: SagaChoreographyRuntimeDescriptor, ISagaChoreographyRuntimeCatalog, /engine/saga-choreographies, and snapshot.SagaChoreographies now keep choreography ownership, transport exposure, feature gates, and result-shape metadata queryable from one shared operator surface without pretending to be live publication-state tracking or replacing the explicit eventing bridge truth
the 2026-04-19 ENG-117 slice shipped the first live choreography publication-state baseline: SagaChoreographyPublicationRuntimeState, ISagaChoreographyPublicationRuntimeStateCatalog, /engine/saga-choreographies/runtime*, and snapshot.SagaChoreographyPublicationStates now keep strategy-owned publication handoff observations queryable by publication, behavior, module, transport, channel, correlation, compensation, and failure posture without collapsing the explicit eventing bridge or downstream dispatch truth into the choreography runtime answer
the 2026-04-19 ENG-118 slice shipped the module-backed saga choreography capability-publication follow-through: Cephalon.Behaviors now publishes behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state only when AddBehaviorPatterns() registers the shared choreography runtime services, and /engine/capabilities plus manifest metadata now keep runtime-catalog versus publication-state ownership explicit without inventing synthetic engine or bridge provenance
continued .NET 11 readiness follow-through, including analyzer drift, package-surface compatibility expectations, any future deployment-mode claim proof beyond the shipped manifest-backed support contract, and the eventual deliberate migration from readiness lane to supported default baseline
Cephalon.Data plus provider families and event-sourcing follow-through
Cephalon.Observability plus dependency-health and exporter/provider conventions
CLI, scaffolding, template, sample, and NuGet publication alignment whenever app-model or package contracts change

Local workspace notes

This snapshot was created from the current local workspace, not from a clean published release artifact.

Observed local notes during the scan:

the git worktree contains local untracked directories such as .build/, .claude/, .dotnet/, .dotnet-cli/, .dotnet-appdata/, and .nuget-appdata/
direct git status required a safe-directory override because the repository ownership on disk differs from the current user context

Those notes may be local-environment artifacts rather than repository-intended state.