Cephalon Engine Backlog

Backlog status in this document reflects the repository state as of April 30, 2026.

Current planning reset (April 2026)

The repo now contains a healthy but mixed set of surfaces:

• intentional taxonomy and descriptor work
• truthful runtime catalogs
• managed execution and provisioning runtimes
• adoption-ready tooling

The current backlog slice is now about keeping the April 2026 maturity reset truthful after the audit baseline, first eventing execution proof, eventing subscription execution binding catalog proof, eventing subscription execution readiness catalog proof, eventing subscription readiness operator-surface proof, eventing in-process subscription execution proof, eventing publication operator-action proof, eventing bounded in-process retry proof, eventing bounded in-process idempotency proof, eventing publication runtime-state proof, Wolverine bounded subscription retry proof, Wolverine bounded dispatch terminal-failure proof, Wolverine dispatch publish-exception proof, first-class event-dispatch terminal-failure operator posture, first agentics managed-execution proof, agentics tool-run operator-surface proof, agentics tool execution operator-action proof, agentics bounded process-local retry proof, agentics process-local duplicate-completed idempotency proof, agentics approval-required and terminal-failure operator posture, first retrieval managed index/query proof, retrieval knowledge-index operator-surface proof, retrieval reindex operator-action proof, retrieval query operator-action proof, retrieval background reindex scheduler proof, multi-tenancy governance-boundary split, first governance membership evaluation proof, invitation validation proof, declared domain-ownership validation proof, approval/remediation action decision proof, in-process governance-action workflow proof, opt-in durable governance-action store proof, opt-in durable governance-membership store proof, opt-in durable governance-invitation store proof, opt-in durable governance-domain ownership store proof, in-process governance domain-ownership verification workflow proof, governance domain-ownership proof-evaluation proof, governance domain-ownership proof-challenge issuance proof, governance domain-ownership proof-publication planning proof, governance domain-ownership HTTP file proof-collection proof, governance domain-ownership proof-verification runner proof, governance domain-ownership DNS TXT proof-collection proof, bounded governance domain-ownership proof-polling runner proof, opt-in governance domain-ownership automatic background proof-polling proof, governance domain-ownership HTTP file proof-publication proof, host-driven governance tenant-administration workflow proof, ASP.NET Core tenant-administration command endpoint proof, host-agnostic governance invitation delivery dispatch proof, ASP.NET Core invitation delivery dispatch endpoint proof, governance invitation delivery retry queue proof, host-agnostic governance invitation delivery status reconciliation proof, ASP.NET Core normalized invitation delivery status callback endpoint proof, ASP.NET Core normalized callback signature verification proof, ASP.NET Core normalized signed-callback replay protection proof, governance invitation delivery status observation-store proof, ASP.NET Core delivery status observation read endpoint proof, ASP.NET Core delivery status observation rollup summary proof, ASP.NET Core delivery status observation attention drill-down proof, ASP.NET Core delivery status observation remediation-hint proof, ASP.NET Core delivery status observation remediation-action filter proof, ASP.NET Core delivery status observation provider-message drill-down proof, SMTP invitation delivery sender proof, SendGrid invitation delivery sender proof, SendGrid Event Webhook callback translation proof, SendGrid signed Event Webhook verification proof, SendGrid signed Event Webhook process-local replay protection proof, SendGrid Event Webhook event-id idempotency proof, Mailgun invitation delivery sender proof, Mailgun webhook callback translation proof, Mailgun signed webhook verification proof, Mailgun signed webhook replay-token protection proof, Mailgun webhook event-id idempotency proof, Microsoft Graph invitation delivery sender proof, Microsoft Graph Azure Identity token-provider proof, Amazon SES invitation delivery sender proof, Amazon SES over SNS callback translation proof, Amazon SES SNS signature verification proof, Amazon SES SNS process-local replay protection proof, Amazon SES SNS message-id idempotency proof, Amazon SES SNS subscription confirmation proof, Amazon SES SNS unsubscribe-confirmation observation proof, and behavior REST profile runtime ownership metadata proof landed.

Current focus:

• keep Engine surface maturity audit authoritative for ownership and proof language
• treat the core eventing execution-binding catalog, abstraction-level execution-readiness catalog, abstraction-level publication dispatcher, abstraction-level publication runtime-state catalog, abstraction-level dispatch-state/summary terminal posture, /engine/event-subscription-readiness, POST /engine/event-publications, /engine/event-publications/runtime*, /engine/event-dispatches/terminal-failures, snapshot.EventSubscriptionExecutionReadiness, snapshot.EventPublicationStates, snapshot.EventDispatchStates, the opt-in direct in-process execution lane, bounded process-local retry metadata, and bounded process-local duplicate-completed execution suppression metadata as adapter-neutral engine-owned proof, while the Wolverine-managed dispatch and event-subscription lanes remain optional provider-managed proofs instead of engine requirements
• treat the Cephalon.Behaviors.Http profile/generated REST lane as a mixed M2 proof: profile metadata stays application-authored and non-publishing, while explicit module-owned activation flows through Cephalon-managed materialization, governance, runtime catalogs, and ownership metadata
• treat the Cephalon.Agentics dispatcher/run-state lane plus bounded process-local retry, duplicate-completed idempotency posture, approval-required filtering, terminal-failure filtering, and the abstraction-level /engine/agent-tool-runs, /engine/agent-tool-runs/retry-pending, /engine/agent-tool-runs/idempotency-duplicates, /engine/agent-tool-runs/approval-required, /engine/agent-tool-runs/terminal-failures, POST /engine/agent-tools/{toolId}/runs, and snapshot.AgentToolRuns seams as the first agentics-family managed/operator proof instead of widening descriptor breadth there again
• treat the Cephalon.Retrieval lexical indexing/query/freshness lane plus the abstraction-level /engine/knowledge-indexes, POST /engine/knowledge-indexes/{collectionId}/queries, POST /engine/knowledge-indexes/{collectionId}/reindex, snapshot.KnowledgeIndexes, and opt-in background reindex scheduler seams as the first retrieval-family managed/operator proof instead of widening catalog breadth there again
• keep Cephalon.MultiTenancy core narrow while Cephalon.MultiTenancy.Governance owns membership catalog/evaluation, local durable stores, invitation delivery dispatch/retry/status reconciliation, delivery-status observation storage, tenant administration, declared domain ownership, proof collection/polling, and governance-action proofs; Cephalon.MultiTenancy.Governance.AspNetCore owns optional fail-closed governance endpoints plus provider-neutral callback signature/replay protection, filtered observation rollup summaries, attention-category drill-down filters, provider-message drill-down filters, remediation-action filters, and deterministic remediation hints over stored observations; HTTP, SMTP, SendGrid, Mailgun, Amazon SES, and Microsoft Graph sender companions own outbound delivery handoff; Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery.AzureIdentity owns the optional Azure Identity access-token provider for the Graph sender; SendGrid ASP.NET Core owns callback translation/signature/replay/event-id hardening; Mailgun ASP.NET Core owns callback translation/signature/replay-token/event-id hardening; and Amazon SES ASP.NET Core owns SNS-wrapped SES event callback translation plus opt-in SNS signature verification, bounded process-local SNS replay protection, observation-store-backed SNS message-id idempotency, opt-in verified SNS subscription confirmation, and opt-in verified SNS unsubscribe-confirmation observation. Distributed or provider-backed membership/invitation/domain/action-store backends, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, cross-node retry leases, provider-specific or distributed callback inboxes, cross-node callback replay protection, distributed event-id ledgers, provider-specific delivery-status callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, remediation execution beyond state transitions, actual DNS proof publication, provider-backed proof publication or mutation, identity-provider synchronization, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, public onboarding, and tenant-admin UI/backoffice flows remain later package-owned work
• treat the ASP.NET Core invitation delivery dispatch endpoint as a bounded action seam over the host-agnostic dispatcher, and treat the delivery-status observation read endpoint plus filtered rollup summaries, attention-category drill-downs, provider-message drill-down filters, remediation-action filters, and remediation hints as a bounded operator/audit projection over the host-agnostic observation store, not provider-specific sender ownership, distributed retry queues, provider-specific callback inboxes, provider polling loops, distributed remediation execution, distributed replay ledgers, or exactly-once delivery claims

ENG-230 Engine surface maturity model and audit baseline

Status: done Estimate: 5 Issue: #775

Why:

• the repo now mixes taxonomy, runtime-truth, and execution-owning surfaces across core engine, technology packs, and provider packs
• downstream package consumers need explicit ownership language before more packages and templates ship outside the repo

Delivered:

• establish the M0 through M4 maturity model and ownership vocabulary for Cephalon surfaces
• classify the current major surfaces in a repo-owned audit
• align docs hub, roadmap, backlog, governance, and project-memory language around the same truth

ENG-231 Truthful managed event-subscription execution baseline

Status: done Estimate: 13

Why:

• Cephalon.Eventing already provides channel descriptors and runtime truth, but it still documents that subscription execution ownership is not yet guaranteed
• the next useful proof is one real managed subscription execution path, not more descriptor breadth

Delivered:

• add host-agnostic managed subscription execution contracts and binding vocabulary through IEventSubscriptionExecutor, EventSubscriptionExecutionContext, and execution-binding descriptors so the core pack can stay adapter-neutral while still projecting runtime ownership truthfully
• keep application-managed versus runtime-bound behavior explicit in event-subscriptions through dispatchRuntime, subscriptionRuntime, executionRuntimeId, executionOwnership, executionMode, and binding.* metadata
• let Cephalon.Eventing.Wolverine opt into one real wolverine-managed execution lane through EnableSubscriptionExecution, fixed-delay retry scheduling, eventing.subscribe, richer wolverine-adapter runtime state, and the existing staged-publication dispatch path
• prove the path with focused composition, hosting, tooling, and regenerated reference-doc coverage

Follow-up later:

• broader inbound broker-consumption ownership, richer retry-policy vocabulary, and non-Wolverine managed subscription proofs remain future work

ENG-232 Agentics tool execution and run-state baseline

Status: done Estimate: 13

Why:

• before this slice, Cephalon.Agentics was valuable as a tool-descriptor and runtime-surface pack, but it still stopped short of tool execution ownership
• downstream teams needed one honest vertical slice before the pack grew more catalogs or helper APIs

Delivered:

• add a host-agnostic managed tool-execution loop through IAgentToolDispatcher, IAgentToolExecutor, AgentToolExecutionRequest, AgentToolExecutionContext, and AgentToolExecutionResult
• publish approval, denial, audit, and projection hooks through IAgentToolExecutionPolicy, IAgentToolExecutionDecision, IAgentToolExecutionObserver, IAgentToolExecutionReport, IAgentToolRunCatalog, and IAgentToolRunReporter
• project execution readiness and run-state truth through the existing agent-tools technology surface, including executionOwnership, executor counts, latest run ids/outcomes, approval posture, terminal-state posture, counters, and reported.* metadata
• prove the slice with focused composition, hosting, package-surface, regenerated reference-doc, and showcase-sample coverage

Follow-up later:

• broader autonomous planning, memory persistence, retry queues, provider-specific AI orchestration, and richer operator automation beyond one bounded manual run remain future work until a package owns those paths explicitly

ENG-233 Retrieval indexing, query execution, and freshness baseline

Status: done Estimate: 13

Why:

• before this slice, Cephalon.Retrieval modeled knowledge collections and retrieval surface truth, but it did not yet own indexing or query execution
• the next useful step is one real retrieval lane with freshness semantics, not broader collection metadata

Delivered:

• add IKnowledgeDocumentProvider, IKnowledgeIndexer, IKnowledgeQueryEngine, IKnowledgeIndexCatalog, request/result contracts, document contracts, and stable indexing/freshness outcome vocabularies
• build one Cephalon-managed in-process lexical index/query lane over registered provider documents while preserving module ownership of source material
• project provider readiness, indexing/query ownership, index outcome counters, document count, query count, freshness state, and query fingerprints through the existing knowledge-collections technology surface
• prove the slice with focused composition, hosting, package-surface, regenerated reference-doc, and showcase-sample coverage

Follow-up later:

• vector databases, embedding pipelines, durable or distributed indexes, rerankers, provider-specific semantic search, and distributed scheduler coordination remain future work until a package owns those paths explicitly; manual operator reindexing later shipped in ENG-268, opt-in in-process background reindexing later shipped in ENG-270, and the bounded query operator action later shipped in ENG-283

ENG-234 Multi-tenancy governance, membership, and domain workflow companion split

Status: done Estimate: 8

Why:

• Cephalon.MultiTenancy already has a truthful narrow runtime slice, but broader governance and membership workflows would blur its adoption story if they land in the base package
• the repo needs a companion-track plan that preserves the thin core while making future governance work intentional

Delivered:

• keep the base package focused on tenant resolution and current runtime truth through the existing tenant-resolution surface
• add tenant-governance-boundaries so membership, invite, domain, and governance workflows are visible outside base-package runtime ownership instead of being implied inside Cephalon.MultiTenancy
• align component, technology-pack, compatibility, operations, architecture, maturity-audit, roadmap, backlog, and project-memory docs so teams understand what belongs in the core versus the future companion surface

Follow-up later:

• use Cephalon.MultiTenancy.Governance for concrete workflow proofs when membership, invitation, domain-ownership, approval, remediation, or tenant-administration paths are owned end to end

ENG-235 Multi-tenancy governance membership evaluation baseline

Status: done Estimate: 13

Why:

• after ENG-234, the base package had a truthful companion boundary, but the governance lane still needed one concrete runtime proof before it should grow broader workflow descriptors
• tenant membership is the smallest useful governance slice because it can be host-agnostic, module-contributed, introspectable, and evaluated without taking over identity-provider or backoffice concerns

Delivered:

• add Cephalon.MultiTenancy.Governance as a separate companion package with AddMultiTenancyGovernance(...), MultiTenancyGovernanceOptions, and the multi-tenancy-governance module
• add membership descriptors, contributor/registry/catalog contracts, and a deterministic ITenantMembershipEvaluator with allowed, no-membership, suspended, expired, missing-role, and disabled outcomes
• publish tenancy.membership.catalog, tenancy.membership.evaluation, stable diagnostics 4510-4511, and the tenant-memberships technology runtime surface with aggregate membership, tenant, contributor, role, and principal-kind posture
• prove the slice with focused composition, hosting, package-surface, and docs/source/planning alignment

Follow-up later:

• declared domain-ownership validation, approval/remediation workflows, durable membership stores, durable invitation stores, invitation delivery, identity-provider synchronization, and tenant administration remained future governance slices after this membership baseline until the package truly owned those paths

ENG-236 Multi-tenancy governance invitation validation baseline

Status: done Estimate: 8

Why:

• after ENG-235, Cephalon.MultiTenancy.Governance owned membership cataloging and evaluation, but invitation workflows were still only a planned boundary entry
• tenant invitations are the next smallest useful governance slice because they can be host-agnostic, module-contributed, introspectable, and validated without taking over email delivery, public-site onboarding, durable stores, or identity-provider synchronization

Delivered:

• add invitation descriptors, contributor/registry/catalog contracts, and a deterministic ITenantInvitationValidator with valid, not-found, accepted, revoked, expired, invitee-mismatch, missing-role, and disabled outcomes
• publish tenancy.invitation.catalog, tenancy.invitation.validation, stable diagnostics 4512-4513, and the tenant-invitations technology runtime surface with aggregate invitation, tenant, contributor, status, role, and invitee-kind posture
• update tenant-governance-boundaries so tenant invitations are a shipped companion-owned lane while the base Cephalon.MultiTenancy package remains tenant-resolution only
• prove the slice with focused composition, hosting, package-surface, and docs/source/planning alignment

Follow-up later:

• declared domain-ownership validation, approval/remediation workflows, durable membership and invitation stores, invitation delivery, identity-provider synchronization, and tenant administration remained future governance slices after this invitation baseline until the package truly owned those paths

ENG-237 Multi-tenancy governance domain ownership validation baseline

Status: done Estimate: 8

Why:

• after ENG-236, Cephalon.MultiTenancy.Governance owned membership and invitation validation, but tenant-domain ownership was still only a planned boundary entry
• declared domain ownership is the next smallest useful governance slice because it can be host-agnostic, module-contributed, introspectable, and validated without taking over DNS polling, HTTP proof hosting, durable stores, public onboarding, or tenant administration

Delivered:

• add domain-ownership descriptors, contributor/registry/catalog contracts, and a deterministic ITenantDomainOwnershipValidator with valid, not-found, tenant-mismatch, pending, rejected, suspended, expired, and disabled outcomes
• publish tenancy.domain-ownership.catalog, tenancy.domain-ownership.validation, stable diagnostics 4514-4515, and the tenant-domain-ownership technology runtime surface with aggregate domain-ownership, tenant, contributor, status, and verification-method posture
• update tenant-governance-boundaries so tenant domain ownership is a shipped companion-owned lane while the base Cephalon.MultiTenancy package remains tenant-resolution only
• prove the slice with focused composition, hosting, package-surface, and docs/source/planning alignment

Follow-up later:

• DNS/HTTP proof collection or external polling, approval/remediation action workflow execution, remediation execution, durable membership/invitation/domain stores, invitation delivery, identity-provider synchronization, and tenant administration remained future governance slices after this domain baseline; action workflow execution is now covered by ENG-239

ENG-238 Multi-tenancy governance action decision baseline

Status: done Estimate: 8

Why:

• after ENG-237, Cephalon.MultiTenancy.Governance owned membership, invitation, and declared domain-ownership validation, but approval/remediation workflows were still only a planned boundary entry
• approval/remediation action decisions are the next smallest useful governance slice because they can be host-agnostic, module-contributed, introspectable, and decided without taking over human workflow execution, durable stores, public onboarding, or tenant administration

Delivered:

• add governance-action descriptors, contributor/registry/catalog contracts, and a deterministic ITenantGovernanceActionDecider with allowed, not-found, tenant-mismatch, action-kind-mismatch, subject-mismatch, pending-approval, rejected, remediation-required, expired, and disabled outcomes
• publish tenancy.governance-action.catalog, tenancy.governance-action.decision, stable diagnostics 4516-4517, and the tenant-governance-actions technology runtime surface with aggregate action, tenant, contributor, status, action-kind, and subject-kind posture
• update tenant-governance-boundaries so tenant governance actions are a shipped companion-owned lane while the base Cephalon.MultiTenancy package remains tenant-resolution only
• prove the slice with focused composition, hosting, package-surface, and docs/source/planning alignment

Follow-up later:

• in-process approval/remediation action workflow execution was intentionally left for follow-up and is now covered by ENG-239
• remediation execution beyond status transitions, durable governance action stores, notification/delivery, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-239 Multi-tenancy governance action workflow execution baseline

Status: done Estimate: 8

Why:

• after ENG-238, Cephalon.MultiTenancy.Governance could catalog and decide approval/remediation actions, but consumers still needed a real package-owned transition path instead of manually rewriting descriptors
• the smallest honest workflow proof is an in-process status-transition service that can mutate the same runtime catalog used by decisions without claiming durable stores, notification delivery, public onboarding, or tenant administration

Delivered:

• add ITenantGovernanceActionWorkflow, workflow request/result contracts, command and outcome vocabularies, and an in-memory runtime action store that feeds the existing action catalog
• support deterministic request, approve, reject, require-remediation, mark-remediated, and expire transitions with tenant, action-kind, and subject-boundary mismatch protection
• publish tenancy.governance-action.workflow, workflow execution ownership metadata, runtime action counts, durable-store and notification-delivery ownership boundaries, and stable diagnostics 4518-4519 through the existing governance action runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• opt-in durable local action storage is now covered by ENG-240
• external human-task inboxes, notification/delivery, remediation execution beyond status transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, tenant administration, public onboarding, and distributed or provider-backed action-store backends remain future governance slices until the package truly owns those paths

ENG-240 Multi-tenancy governance durable action store baseline

Status: done Estimate: 8

Why:

• after ENG-239, Cephalon.MultiTenancy.Governance owned real workflow transitions, but runtime action state was still process-local unless the consumer supplied its own store
• the smallest honest durability proof is a host-agnostic action-store contract with an in-memory default and an opt-in local JSON store, not a full human-task or tenant-admin workflow

Delivered:

• add public ITenantGovernanceActionStore plus built-in in-memory and file-backed implementations selected through MultiTenancyGovernanceOptions.GovernanceActionStoreFilePath
• route workflow-created and workflow-transitioned runtime actions through the store, return store-failed without marking transitions applied when persistence fails, and merge stored actions back into the same action catalog used by decisions
• publish tenancy.governance-action.store, action-store kind/durability/ownership metadata, durable-store ownership truth, and stable diagnostics 4520-4521 through the existing governance action runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• opt-in durable local membership storage is now covered by ENG-241
• durable invitation storage is now covered by ENG-242
• durable domain ownership storage is now covered by ENG-243
• distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, remediation execution beyond status transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-241 Multi-tenancy governance durable membership store baseline

Status: done Estimate: 8

Why:

• after ENG-240, Cephalon.MultiTenancy.Governance had a durable action-store proof, but tenant membership state still came only from process-local descriptors unless the consumer app owned storage itself
• the smallest honest membership durability proof is a host-agnostic membership-store contract with an in-memory default and an opt-in local JSON store, not a full identity-provider sync, invitation lifecycle, or tenant-admin workflow

Delivered:

• add public ITenantMembershipStore plus built-in in-memory and file-backed implementations selected through MultiTenancyGovernanceOptions.MembershipStoreFilePath
• merge stored memberships into the same membership catalog used by ITenantMembershipEvaluator, so runtime Upsert(...) calls are immediately visible to catalog reads, evaluations, /engine/technology-surfaces, and /engine/snapshot
• publish tenancy.membership.store, membership-store kind/durability/ownership metadata, durable-store ownership truth, and runtime membership counts through the existing tenant-memberships runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• durable invitation storage is now covered by ENG-242
• durable domain ownership storage is now covered by ENG-243
• distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, remediation execution beyond status transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-242 Multi-tenancy governance durable invitation store baseline

Status: done Estimate: 8

Why:

• after ENG-241, Cephalon.MultiTenancy.Governance had durable action and membership store proofs, but tenant invitation state still came only from process-local descriptors unless the consumer app owned storage itself
• the smallest honest invitation durability proof is a host-agnostic invitation-store contract with an in-memory default and an opt-in local JSON store, not a full invitation delivery, public onboarding, or identity-provider sync workflow

Delivered:

• add public ITenantInvitationStore plus built-in in-memory and file-backed implementations selected through MultiTenancyGovernanceOptions.InvitationStoreFilePath
• merge stored invitations into the same invitation catalog used by ITenantInvitationValidator, so runtime Upsert(...) calls are immediately visible to catalog reads, validation, /engine/technology-surfaces, and /engine/snapshot
• publish tenancy.invitation.store, invitation-store kind/durability/ownership metadata, durable-store ownership truth, and runtime invitation counts through the existing tenant-invitations runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• durable domain ownership storage is now covered by ENG-243
• distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, DNS/HTTP proof collection or external polling, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-243 Multi-tenancy governance durable domain ownership store baseline

Status: done Estimate: 8

Why:

• after ENG-242, Cephalon.MultiTenancy.Governance had durable action, membership, and invitation store proofs, but tenant-domain ownership state still came only from process-local descriptors unless the consumer app owned storage itself
• the smallest honest domain-ownership durability proof is a host-agnostic domain-ownership store contract with an in-memory default and an opt-in local JSON store, not DNS/HTTP proof collection or external polling, domain lifecycle automation, or tenant-admin workflow

Delivered:

• add public ITenantDomainOwnershipStore plus built-in in-memory and file-backed implementations selected through MultiTenancyGovernanceOptions.DomainOwnershipStoreFilePath
• merge stored domain ownership declarations into the same domain-ownership catalog used by ITenantDomainOwnershipValidator, so runtime Upsert(...) calls are immediately visible to catalog reads, validation, /engine/technology-surfaces, and /engine/snapshot
• publish tenancy.domain-ownership.store, domain-ownership-store kind/durability/ownership metadata, durable-store ownership truth, and runtime domain ownership counts through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• in-process domain-ownership verification workflow transitions are now covered by ENG-244
• distributed or provider-backed membership/invitation/domain/action-store backends, DNS/HTTP proof collection or external polling, domain lifecycle automation beyond status transitions, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-244 Multi-tenancy governance domain ownership verification workflow baseline

Status: done Estimate: 8

Why:

• after ENG-243, Cephalon.MultiTenancy.Governance could persist runtime tenant-domain ownership declarations, but consumers still had to mutate descriptor state themselves to move pending domains through verification outcomes
• the smallest honest workflow proof is an in-process status-transition service that writes through the same domain-ownership store and catalog used by validation, not DNS polling, HTTP proof hosting, domain lifecycle automation, or tenant-admin workflow

Delivered:

• add public ITenantDomainOwnershipVerificationWorkflow, workflow request/result contracts, command and outcome vocabularies, and guarded runtime transition behavior over ITenantDomainOwnershipStore
• support deterministic request, verify, reject, suspend, and expire transitions with cross-tenant domain protection, verification-method mismatch protection, workflow evidence metadata, and store-failed outcomes when persistence fails
• publish tenancy.domain-ownership.workflow, verification-workflow ownership metadata, DNS/HTTP proof-collection ownership boundaries, and stable diagnostics 4522-4525 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• DNS/HTTP proof collection or external polling, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-245 Multi-tenancy governance domain ownership proof evaluation baseline

Status: done Estimate: 8

Why:

• after ENG-244, Cephalon.MultiTenancy.Governance could transition domain ownership status, but consumers still had to decide whether reported DNS/HTTP/manual evidence matched the expected proof before calling verify or reject
• the smallest honest next proof is a host-agnostic evaluator that consumes application/provider-reported evidence, compares it against an expected proof value, and applies the existing workflow; it should not claim DNS polling, HTTP fetching, or external collection ownership yet

Delivered:

• add public ITenantDomainOwnershipProofEvaluator, proof-evaluation request/result contracts, outcome vocabulary, and stable proof metadata keys
• support exact trimmed proof comparison against an expected proof supplied on the request or descriptor metadata (expectedProof, expectedDnsTxtProof, or expectedHttpFileProof), then apply verify for matches or reject for mismatches through ITenantDomainOwnershipVerificationWorkflow
• record proof-evaluation ownership, source, actor, correlation id, and SHA-256 proof fingerprints in descriptor metadata without adding observed raw proof values
• publish tenancy.domain-ownership.proof-evaluation, proof-evaluation runtime-surface metadata, and stable diagnostics 4526-4527 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• DNS/HTTP proof collection or external polling, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths

ENG-246 Multi-tenancy governance domain ownership proof challenge issuance baseline

Status: done Estimate: 8

Why:

• after ENG-245, Cephalon.MultiTenancy.Governance could evaluate reported DNS/HTTP/manual proof evidence, but consumers still had to invent and persist the expected proof challenge values themselves
• the smallest honest next proof is a host-agnostic challenge issuer that generates or accepts a challenge token, records expected proof metadata, gives DNS TXT or HTTP file publication hints, and writes the pending declaration through the existing domain-ownership store without claiming DNS/HTTP publication or external polling

Delivered:

• add public ITenantDomainOwnershipProofChallengeIssuer, proof-challenge request/result contracts, outcome vocabulary, and stable challenge metadata keys
• generate secure cephalon-domain-proof-* challenge values when callers do not supply one, store expectedProof plus method-specific expected-proof metadata, and expose default DNS TXT record / HTTP file publication hints
• create or refresh pending domain-ownership declarations through ITenantDomainOwnershipStore, protect already verified or suspended declarations from accidental re-challenge, and report store failures without claiming a challenge was applied
• publish tenancy.domain-ownership.proof-challenge, proof-challenge runtime-surface metadata, and stable diagnostics 4528-4529 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• on-demand HTTP file proof collection is now covered by ENG-248
• configured on-demand DNS TXT proof collection is now covered by ENG-250
• bounded on-demand proof polling is now covered by ENG-251
• automatic background proof polling is now covered by ENG-252
• actual DNS proof publication, provider-backed proof publication or mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; HTTP file proof publication was then narrowed and shipped in ENG-253

ENG-247 Multi-tenancy governance domain ownership proof publication planning baseline

Status: done Estimate: 8

Why:

• after ENG-246, Cephalon.MultiTenancy.Governance could issue expected proof values and DNS TXT / HTTP file hints, but consumers still had to assemble exact publication instructions and track that planning step themselves
• the smallest honest next proof is a host-agnostic publication planner that turns issued challenge metadata into deterministic DNS TXT or HTTP file instructions, optionally records planning metadata through the existing domain-ownership store, and keeps actual DNS mutation plus HTTP hosting outside the engine at that slice boundary; HTTP file hosting was later narrowed and shipped in ENG-253

Delivered:

• add public ITenantDomainOwnershipProofPublicationPlanner, proof-publication plan request/result contracts, outcome vocabulary, and stable plan metadata keys
• emit exact DNS TXT record name/value or HTTP file path/content/content-type instructions from expected proof metadata and challenge hints without mutating DNS or hosting files
• optionally record plan outcome, source, actor, correlation id, proof fingerprints, and ownership metadata through ITenantDomainOwnershipStore; report store failures without returning stale instructions as planned
• publish tenancy.domain-ownership.proof-publication-plan, proof-publication planning runtime-surface metadata, and stable diagnostics 4530-4531 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• on-demand HTTP file proof collection is now covered by ENG-248
• configured on-demand DNS TXT proof collection is now covered by ENG-250
• bounded on-demand proof polling is now covered by ENG-251
• automatic background proof polling is now covered by ENG-252
• actual DNS proof publication, provider-backed proof publication or mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; HTTP file proof publication was then narrowed and shipped in ENG-253

ENG-248 Multi-tenancy governance domain ownership HTTP proof collection baseline

Status: done Estimate: 8

Why:

• after ENG-247, Cephalon.MultiTenancy.Governance could emit exact HTTP file publication instructions, but consumers and provider packs still had to fetch HTTP proof bodies and report them into the evaluator themselves
• the smallest honest next proof is an on-demand HTTP file collector that uses the existing publication planner and proof evaluator, records safe collection metadata, and keeps DNS TXT collection, actual publication, provider mutation, and background polling outside the engine at that slice boundary

Delivered:

• add public ITenantDomainOwnershipHttpProofCollector, HTTP proof-collection request/result contracts, outcome vocabulary, and stable collection metadata keys
• collect HTTP file proof content through a bounded default HttpClient, require host-matched HTTPS by default, reject unsupported methods, unsafe URIs, non-OK status codes, empty bodies, oversized responses, and request failures, then feed the observed body into ITenantDomainOwnershipProofEvaluator
• publish tenancy.domain-ownership.http-proof-collection, HTTP proof-collection runtime-surface metadata, then-pending DNS TXT collection boundary plus external polling ownership boundary, and stable diagnostics 4532-4533 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• actual DNS proof publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; DNS TXT proof collection was then narrowed and shipped in ENG-250, bounded on-demand proof polling was then narrowed and shipped in ENG-251, automatic background proof polling was then narrowed and shipped in ENG-252, and HTTP file proof publication was then narrowed and shipped in ENG-253

ENG-249 Multi-tenancy governance domain ownership proof verification runner baseline

Status: done Estimate: 8

Why:

• after ENG-248, Cephalon.MultiTenancy.Governance owned the narrower challenge, publication-plan, proof-evaluation, and HTTP file proof-collection services, but consumer apps still had to decide which service to call and how to present one operator-facing answer
• the smallest honest next proof is a host-agnostic runner that composes the owned services through one entry point without claiming DNS TXT collection at that slice boundary, actual publication, provider mutation, background polling, tenant-admin workflow, or public onboarding

Delivered:

• add public ITenantDomainOwnershipProofVerificationRunner, proof-verification request/result contracts, outcome vocabulary, and stable returned metadata keys
• support challenge issuance plus publication planning when expected proof is missing, explicit observed-proof evaluation for manual/DNS/HTTP reports, and optional built-in HTTP file proof collection for http-file declarations
• publish tenancy.domain-ownership.proof-verification-runner, proof-verification runner runtime-surface metadata, then-pending DNS TXT collection boundary plus external polling ownership boundary, and stable diagnostics 4534-4535 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, and docs/source/planning alignment

Follow-up later:

• actual DNS proof publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; DNS TXT proof collection was then narrowed and shipped in ENG-250, bounded on-demand proof polling was then narrowed and shipped in ENG-251, automatic background proof polling was then narrowed and shipped in ENG-252, and HTTP file proof publication was then narrowed and shipped in ENG-253

ENG-250 Multi-tenancy governance domain ownership DNS TXT proof collection baseline

Status: done Estimate: 8

Why:

• after ENG-249, the proof-verification runner could orchestrate challenge issuance, publication planning, supplied-proof evaluation, and optional HTTP file proof collection, but DNS TXT declarations still needed application or provider code to report observed TXT evidence
• the smallest honest next proof is a host-agnostic DNS TXT collector that uses the existing publication planner and proof evaluator, requires an explicit DNS-over-HTTPS resolver endpoint, and avoids hidden public network defaults or raw proof leakage

Delivered:

• add public ITenantDomainOwnershipDnsTxtProofCollector, DNS TXT proof-collection request/result contracts, outcome vocabulary, and stable safe metadata keys
• collect TXT answers through a bounded DNS-over-HTTPS JSON resolver, require an explicit resolver endpoint, normalize quoted/chunked TXT values, evaluate exact expected-proof matches, and record resolver/status/count/fingerprint metadata instead of raw observed proof values
• integrate DNS TXT collection into ITenantDomainOwnershipProofVerificationRunner for dns-txt declarations while keeping per-request opt-out and resolver override controls
• publish tenancy.domain-ownership.dns-txt-proof-collection, DNS TXT proof-collection runtime-surface metadata, configured resolver ownership truth, and stable diagnostics 4536-4537 through the existing tenant-domain-ownership runtime surface
• prove the slice with focused composition, hosting, package-surface, reference-doc, pack, and docs/source/planning alignment

Follow-up later:

• bounded on-demand proof polling is now covered by ENG-251
• automatic background proof polling is now covered by ENG-252
• actual DNS proof publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; HTTP file proof publication was then narrowed and shipped in ENG-253

ENG-251 Multi-tenancy governance domain ownership proof polling runner baseline

Status: done Estimate: 8

Why:

• after ENG-250, the verification runner could collect HTTP file and configured DNS TXT proofs, but consumer apps still had to write the loop that selected pending or rejected declarations and retried them safely
• the smallest honest next proof is a bounded on-demand polling runner that owns the selection/orchestration loop while still leaving automatic scheduling, DNS publication, HTTP publication, and provider mutation outside the package at that slice boundary; automatic scheduling later shipped in ENG-252 and HTTP file proof publication later shipped in ENG-253

Delivered:

• add public ITenantDomainOwnershipProofPollingRunner, proof-polling request/result contracts, outcome vocabulary, safe metadata keys, and default batch-limit options
• scan the domain-ownership catalog for pending or rejected HTTP file and DNS TXT declarations, skip verified/suspended/expired/manual declarations by default, respect tenant/domain/method filters and batch limits, and delegate each attempt to ITenantDomainOwnershipProofVerificationRunner
• publish tenancy.domain-ownership.proof-polling-runner, proof-polling runner runtime-surface metadata, externalProofPollingOwnership = cephalon-managed, backgroundProofPollingOwnership = application-managed, and stable diagnostics 4538-4539
• prove the slice with focused composition, hosting, package-surface, reference-doc, pack, and docs/source/planning alignment

Follow-up later:

• automatic background proof polling is now covered by ENG-252
• actual DNS proof publication, provider-backed collection/mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; HTTP file proof publication was then narrowed and shipped in ENG-253

ENG-252 Multi-tenancy governance automatic background proof polling baseline

Status: done Estimate: 8

Why:

• after ENG-251, Cephalon.MultiTenancy.Governance owned the bounded on-demand proof-polling loop, but consumer apps still had to write their own scheduler and last-run runtime reporting
• the smallest honest next proof is an opt-in generic-host background service that schedules the existing bounded runner and reports run state without starting surprise network I/O by default or claiming DNS/HTTP publication/provider mutation ownership

Delivered:

• add MultiTenancyGovernanceOptions.EnableDomainOwnershipProofBackgroundPolling, interval/source/startup controls, and an opt-in hosted-service path backed by Microsoft.Extensions.Hosting
• add public ITenantDomainOwnershipProofPollingRuntimeCatalog plus TenantDomainOwnershipProofPollingRuntimeSnapshot so operators can inspect enablement, ownership, interval, batch, run counts, latest timestamps, latest outcome, and latest candidate/verification/verified/rejected/failed counts
• publish tenancy.domain-ownership.proof-background-polling, backgroundProofPollingOwnership = cephalon-managed when effectively enabled, runtime-surface metadata, and stable diagnostics 4540-4543
• prove the slice with focused composition, package-surface, reference-doc, pack, and docs/source/planning alignment

Follow-up later:

• actual DNS proof publication, provider-backed proof publication or mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, notification/delivery, invitation delivery, remediation execution beyond status transitions, identity-provider synchronization, tenant administration, and public onboarding remain future governance slices until the package truly owns those paths; HTTP file proof publication is now covered by ENG-253

ENG-253 Multi-tenancy governance HTTP proof publication baseline

Status: done Estimate: 8

Why:

• after ENG-252, Cephalon.MultiTenancy.Governance could issue, plan, collect, evaluate, poll, and schedule tenant-domain ownership proofs, but consumer apps still had to host the actual HTTP proof file themselves
• the smallest honest next proof is host-agnostic HTTP proof publication state plus an optional ASP.NET Core serving adapter, without claiming DNS mutation, provider control-plane mutation, tenant-admin workflow, or public onboarding

Delivered:

• add public ITenantDomainOwnershipHttpProofPublisher, ITenantDomainOwnershipHttpProofPublicationCatalog, publication request/result/descriptor/outcome contracts, and safe publication metadata keys
• materialize HTTP file proof publication from the existing publication planner into the domain-ownership store, publish tenancy.domain-ownership.http-proof-publication, HTTP publication ownership/count runtime metadata, and stable diagnostics 4544-4545
• add Cephalon.MultiTenancy.Governance.AspNetCore with opt-in MapCephalonTenantDomainOwnershipHttpProofs() routing so ASP.NET Core hosts can serve published proof files from the host-agnostic catalog
• prove the slice with focused composition, hosting, package-surface, reference-doc, pack, and docs/source/planning alignment

Follow-up later:

• actual DNS proof publication, provider-backed proof publication or mutation, domain lifecycle automation beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, external human-task inboxes, provider-specific notification/invitation senders, remediation execution beyond status transitions, identity-provider synchronization, tenant-admin UI/backoffice flows, and public onboarding remain future governance slices until the package truly owns those paths; host-driven tenant administration workflow commands are now covered by ENG-254, the ASP.NET Core command endpoint is covered by ENG-255, and host-agnostic invitation delivery dispatch is covered by ENG-256

ENG-254 Multi-tenancy governance tenant administration workflow baseline

Status: done Estimate: 8

Why:

• after ENG-253, membership and invitation stores, catalogs, evaluator, and validator existed, but consumer apps still had to hand-write basic tenant-administration transitions
• the smallest honest proof is host-driven in-process commands over existing stores without claiming onboarding, delivery, endpoints/UI, or identity-provider sync

Delivered:

• add public ITenantAdministrationWorkflow plus request, result, command, outcome, and metadata-key contracts
• implement grant, suspend, and expire membership commands plus issue, accept, revoke, and expire invitation commands over the existing stores, with store-failed outcomes and workflow metadata
• publish tenancy.administration.workflow, the tenant-administration runtime surface, base-package boundary truth, and stable diagnostics 4546-4547
• prove the slice with focused composition/tooling coverage plus docs/source/planning/reference alignment

Follow-up later:

• tenant-admin backoffice UI, public onboarding, provider-specific email/SMS/chat/CRM/identity-provider invitation senders, identity-provider synchronization, remediation execution beyond state transitions, distributed/provider-backed governance stores, and actual DNS/provider proof publication remain future governance slices until a package truly owns those paths; the ASP.NET Core command endpoint is now covered by ENG-255, host-agnostic invitation delivery dispatch is covered by ENG-256, and the generic HTTP webhook sender is covered by ENG-257

ENG-255 Multi-tenancy governance ASP.NET Core tenant administration endpoint baseline

Status: done Estimate: 8

Why:

• after ENG-254, the governance package owned real tenant-administration commands, but ASP.NET Core consumers still had to hand-write the HTTP glue to invoke them safely
• the smallest honest next proof is an optional command endpoint over the existing workflow, not a tenant-admin UI, public onboarding flow, delivery system, or identity-provider sync

Delivered:

• add public MapCephalonTenantAdministrationCommands() routing for POST /engine/tenant-administration/commands over ITenantAdministrationWorkflow
• keep the endpoint fail-closed by default, with RequireTenantAdministrationAuthorization, optional TenantAdministrationAuthorizationPolicy, route, enablement, and endpoint-description configuration under Engine:MultiTenancy:Governance:AspNetCore
• publish the tenant-administration-http-endpoints runtime surface with mapped/configured/disabled state, route, authorization posture, and application-managed UI/onboarding/delivery/identity boundaries
• prove the slice with focused hosting, package-surface, reference-doc, source, component-doc, operations, compatibility, roadmap, backlog, and project-memory alignment

Follow-up later:

• tenant-admin backoffice UI, public onboarding, provider-specific notification/invitation senders, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths; host-agnostic invitation delivery dispatch is now covered by ENG-256

ENG-256 Multi-tenancy governance invitation delivery dispatch baseline

Status: done Estimate: 8

Why:

• after ENG-255, the governance family could issue invitations and expose an optional tenant-administration command endpoint, but consumer apps still had to hand-write dispatch, sender selection, outcome metadata, and runtime reporting
• the smallest honest next proof is host-agnostic dispatch through registered sender extensions, not a built-in email/SMS/identity-provider sender or public onboarding flow

Delivered:

• add public ITenantInvitationDeliveryDispatcher, ITenantInvitationDeliverySender, ITenantInvitationDeliveryRunCatalog, request/result/context/sender-result/run/outcome/metadata-key contracts, and a bounded in-memory run catalog
• implement pending/unexpired invitation lookup over the merged invitation catalog, deterministic sender selection, sender-not-configured, sender-failed, suppressed, store-failed, and dispatched outcomes, and delivery outcome metadata persistence through ITenantInvitationStore
• publish tenancy.invitation.delivery-dispatch, stable diagnostics 4548-4549, and tenant-invitations/tenant-administration runtime metadata for dispatch ownership, sender readiness, external delivery ownership, run counts, and latest delivery outcome
• prove the slice with focused composition, package-surface, reference-doc, source, component-doc, operations, compatibility, roadmap, backlog, and project-memory alignment

Follow-up later:

• provider-specific email/SMS/chat/identity-provider invitation senders, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths

ENG-257 Multi-tenancy governance HTTP invitation delivery sender baseline

Status: done Estimate: 8

Why:

• after ENG-256, the governance core owned truthful dispatch, sender selection, run-state, and outcome recording, but consumer apps still had to implement every concrete sender before the path could call a real external notification or onboarding system
• the smallest honest next proof is a generic HTTP webhook sender over the existing ITenantInvitationDeliverySender extension point, not a SendGrid/Mailgun/Twilio/chat/identity-provider-specific connector

Delivered:

• add Cephalon.MultiTenancy.Governance.HttpDelivery as an optional companion package with HttpInvitationDeliveryOptions, AddCephalonHttpInvitationDelivery(...), and HttpInvitationDeliveryPayload
• implement a provider-managed http-webhook sender that posts bounded JSON payloads to configured HTTP or HTTPS endpoints, supports configurable method, timeout, headers, accepted status codes, supported channels, provider-message id header capture, and safe sender metadata
• publish diagnostics 4550-4551, add the package to the supported reference-doc/default catalog and package-surface guardrails, and prove dispatched/suppressed outcomes through focused composition tests over the existing governance dispatcher and store metadata
• keep provider-specific email/SMS/chat/CRM/identity-provider semantics, distributed retry queues, callbacks, public onboarding, tenant-admin UI, and identity-provider sync outside this proof

Follow-up later:

• provider-specific email/SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, callback reconciliation, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths; webhook signing is covered by ENG-258, bounded in-process retry is covered by ENG-259, and the host-agnostic local retry store/runner plus opt-in background scheduler is covered by ENG-290

ENG-258 Multi-tenancy governance HTTP invitation delivery webhook signing baseline

Status: done Estimate: 5

Why:

• after ENG-257, Cephalon.MultiTenancy.Governance.HttpDelivery could send real webhook payloads, but receivers still needed a trustworthy way to verify that a dispatch request came from the configured Cephalon host and that the body was not altered in transit
• the smallest honest security proof is package-owned HMAC signing over the exact serialized payload and dispatch timestamp, not a provider-specific email/SMS/chat/identity-provider connector or a callback reconciliation loop

Delivered:

• add SigningSecret, SigningKeyId, and configurable signature header names to HttpInvitationDeliveryOptions
• sign {unixTimestamp}.{jsonBody} with HMAC-SHA256 when SigningSecret is configured, emit v1=<lowercase hex> signature, timestamp, and optional key-id headers, and record only safe httpSigned/httpSigningKeyId metadata
• preserve unsigned behavior when no signing secret is configured and prove signed delivery through focused composition coverage over the existing governance dispatcher and HTTP sender
• keep provider-specific auth semantics, distributed retry queues, provider-specific delivery-status callback endpoints or provider polling, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation outside this proof

Follow-up later:

• provider-specific email/SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, provider-specific delivery-status callback endpoints or provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths; bounded in-process retry is covered by ENG-259, host-agnostic delivery status reconciliation is covered by ENG-261, and the host-agnostic local retry store/runner plus opt-in background scheduler is covered by ENG-290

ENG-259 Multi-tenancy governance HTTP invitation delivery retry baseline

Status: done Estimate: 5

Why:

• after ENG-258, Cephalon.MultiTenancy.Governance.HttpDelivery could send and sign real webhook payloads, but transient webhook responses or temporary transport failures still completed as single-shot sender failures
• the smallest honest reliability proof is bounded in-process retry/backoff inside the existing HTTP sender, not a package-owned durable delivery store, provider callback endpoint, provider-specific invitation connector, or distributed scheduler

Delivered:

• add MaxAttempts, RetryDelayMilliseconds, RetryStatusCodes, and RetryTransportFailures to HttpInvitationDeliveryOptions, with configuration binding and XML comments for generated reference docs
• create a fresh HTTP request per attempt over the same serialized payload, retry configured transient status codes plus transient transport failures when attempts remain, and keep TimeoutSeconds as the dispatch budget for the attempt loop
• record safe attempt/retry metadata such as httpAttemptCount, httpMaxAttempts, httpRetried, httpRetryReason, httpRetryDelayMilliseconds, and httpRetryStatusCodes without copying secrets or signatures
• prove retry behavior through focused composition coverage over the existing governance dispatcher and HTTP sender
• keep distributed retry queues, provider-specific delivery-status callback endpoints or provider polling, provider-specific email/SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation outside this proof

Follow-up later:

• provider-specific email/SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, cross-node retry leases, provider-specific delivery-status callback endpoints or provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths; provider-neutral idempotency headers are covered by ENG-260, host-agnostic delivery status reconciliation is covered by ENG-261, the host-agnostic local retry store/runner is covered by ENG-290, opt-in background retry scheduling is covered by ENG-291, and process-local retry execution coordination is covered by ENG-292

ENG-260 Multi-tenancy governance HTTP invitation delivery idempotency baseline

Status: done Estimate: 5

Why:

• after ENG-259, Cephalon.MultiTenancy.Governance.HttpDelivery could retry transient webhook outcomes, but receivers still needed a stable provider-neutral key to suppress duplicate side effects across retry attempts
• the smallest honest safety proof is an idempotency header produced by the HTTP sender, not retry scheduling ownership, distributed retry ownership, provider callback endpoint, or provider-specific invitation connector

Delivered:

• add EnableIdempotencyHeader, IdempotencyHeaderName, and IdempotencyMetadataKey to HttpInvitationDeliveryOptions, with configuration binding and XML comments for generated reference docs
• send the configured idempotency header on every webhook attempt, using caller-supplied header-safe dispatch metadata when present, hashing overlong/header-unsafe metadata values, or deriving a hashed key from tenant id, invitation id, channel, and sender id when absent
• keep the same idempotency key across retry attempts and record safe httpIdempotencyHeaderName, httpIdempotencyKey, and httpIdempotencyKeySource metadata
• prove default derived keys and metadata-supplied keys through focused composition coverage over the existing governance dispatcher and HTTP sender
• keep distributed retry queues, provider-specific delivery-status callback endpoints or provider polling, provider-specific email/SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation outside this proof

Follow-up later:

• host-agnostic delivery status reconciliation is covered by ENG-261; provider-specific email/SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, cross-node retry leases, provider-specific delivery-status callback endpoints or provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths; the host-agnostic local retry store/runner is covered by ENG-290, opt-in background retry scheduling is covered by ENG-291, and process-local retry execution coordination is covered by ENG-292

ENG-261 Multi-tenancy governance invitation delivery status reconciliation baseline

Status: done Estimate: 5

Why:

• after ENG-260, the HTTP sender could emit safe idempotent delivery attempts, but the governance core still had no host-agnostic place to record provider or receiver delivery status observations
• the smallest honest ownership proof is a reconciler over existing invitation store metadata, not a provider webhook endpoint, provider polling loop, automatic retry scheduler, distributed retry queue, or provider-specific invitation connector

Delivered:

• add ITenantInvitationDeliveryStatusReconciler, status request/result contracts, stable status/outcome vocabularies, and status metadata keys to Cephalon.MultiTenancy.Governance
• reconcile status observations through the merged invitation catalog and ITenantInvitationStore, including provider message id matching so callbacks cannot be attached to the wrong invitation silently
• publish tenancy.invitation.delivery-status-reconciliation, stable diagnostics 4552-4553, and tenant-invitations/tenant-administration runtime metadata for status reconciliation ownership, external status ownership, reported status count, latest status, and latest observed timestamp
• prove successful reconciliation and provider-message mismatch rejection through focused composition coverage, and keep package/reference-doc surface tests aligned
• keep provider-specific delivery-status callback endpoints, provider polling, distributed retry queues, provider-specific email/SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider sync, and provider mutation outside this proof

Follow-up later:

• provider-specific email/SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, cross-node retry leases, provider-specific delivery-status callback endpoints or provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths; the host-agnostic local retry store/runner is covered by ENG-290, opt-in background retry scheduling is covered by ENG-291, and process-local retry execution coordination is covered by ENG-292

ENG-262 Behavior REST profile runtime ownership metadata baseline

Status: done Estimate: 5

Why:

• Cephalon.Behaviors.Http had already shipped module-owned MapProfile<TBehavior>(), MapGeneratedProfiles(...), candidate catalogs, runtime catalogs, and governance truth, but the maturity audit still described the lane as metadata-only M1
• the smallest honest proof is to make runtime ownership visible in the existing REST endpoint payloads without claiming that [AppBehavior] or BehaviorRestProfileAttribute publishes public REST by itself

Delivered:

• add RestEndpointRuntimeMetadataKeys to Cephalon.Abstractions.Transports so consumers can read stable REST runtime metadata keys instead of hard-coding ownership strings
• publish restPublicationActivationOwnership = application-managed, restMaterializationOwnership = cephalon-managed, restProfileMetadataOwnership = application-managed, and restPublicationActivationMode on behavior-backed profile/generated REST endpoints
• keep the metadata visible through /engine/rest-endpoints, /engine/rest-endpoint-candidates, and snapshot.RestEndpoints for both MapProfile<TBehavior>() and generated-profile shorthand paths
• promote the Cephalon.Behaviors.Http maturity-audit row to mixed M2 while preserving the contract that profile attributes are metadata-only until a module or host explicitly activates publication
• prove the runtime/catalog path through focused hosting coverage and package-surface coverage — issue #771

Follow-up later:

• adoption samples, operator automation, and richer docs can build on the same explicit module-owned activation path; ambient behavior-to-REST auto-publication remains out of scope unless a future proof preserves the same ownership split

ENG-263 Eventing subscription execution binding catalog baseline

Status: done Estimate: 5

Why:

• Cephalon.Eventing already had adapter-neutral subscription execution binding contributors, but downstream code still had to inspect the event-subscriptions metadata payload to read the active binding set
• the smallest honest next proof is a public core read contract plus stable metadata vocabulary, not a second broker story or a mandatory Wolverine dependency

Delivered:

• add IEventSubscriptionExecutionBindingCatalog so hosts and companion packs can read active managed subscription bindings directly by subscription id
• add EventSubscriptionRuntimeMetadataKeys so operator/runtime consumers can reference stable event-subscriptions metadata keys such as dispatchRuntime, subscriptionRuntime, executionRuntimeId, executionOwnership, executionMode, binding.*, and reported.*
• keep Cephalon.Eventing.Wolverine as the optional provider-managed proof that contributes a wolverine-managed binding through the existing adapter-neutral contributor seam
• prove both the application-managed empty-catalog path and the Wolverine-managed bound path through focused composition, package-surface, and reference-doc coverage — issue #772

Follow-up later:

• richer retry-policy vocabulary, generic inbound broker consumption, non-Wolverine managed subscription proofs, and operator automation remain future work until a package truly owns those paths

ENG-264 Eventing subscription execution readiness catalog baseline

Status: done Estimate: 5

Why:

• after ENG-263, hosts and companion packs could read active managed bindings directly, but they still lacked a public answer for subscriptions that are declared-only, hosted-execution-linked, or application-managed through runtime reports
• the smallest honest next proof is a core readiness catalog that explains the current execution posture without claiming that Cephalon.Eventing owns a generic broker or inbox runtime

Delivered:

• add EventSubscriptionExecutionReadinessDescriptor, EventSubscriptionExecutionReadinessStates, and IEventSubscriptionExecutionReadinessCatalog
• derive readiness from the existing declared subscription catalog, managed binding catalog, hosted-execution links, and application-managed runtime reports
• project executionReadiness, executionPath, and executionReadinessReasons through the existing event-subscriptions technology surface
• prove declared-only, application-managed reported, hosted-execution-linked, and Wolverine runtime-bound paths through focused composition, package-surface, and reference-doc coverage — issue #773

Follow-up later:

• richer retry-policy vocabulary, generic inbound broker consumption, non-Wolverine managed subscription proofs, and operator automation remain future work until a package truly owns those paths

ENG-265 Eventing subscription readiness operator-surface baseline

Status: done Estimate: 5 Issue: #774

Why:

• after ENG-264, readiness existed as a public catalog in the eventing package, but ASP.NET Core hosts and /engine/snapshot could not expose it without depending directly on Cephalon.Eventing
• the smallest honest next proof is to promote the read contract to the host-agnostic abstraction layer, then project it through the existing operator surfaces while keeping the implementation in the selected eventing pack

Delivered:

• move EventSubscriptionExecutionReadinessDescriptor, EventSubscriptionExecutionReadinessStates, and IEventSubscriptionExecutionReadinessCatalog to Cephalon.Abstractions.Data
• keep Cephalon.Eventing as the implementation owner for the merged readiness answer over declared subscriptions, managed bindings, hosted execution links, and application-managed runtime reports
• add /engine/event-subscription-readiness, /engine/event-subscription-readiness/{subscriptionId}, and snapshot.EventSubscriptionExecutionReadiness
• prove the declared-only operator route, missing-subscription 404, package-surface, generated reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• richer retry-policy vocabulary, generic inbound broker consumption, non-Wolverine managed subscription proofs, and operator automation remain future work until a package truly owns those paths

ENG-266 Agentics tool-run operator-surface baseline

Status: done Estimate: 5

Why:

• after ENG-232, tool execution and run-state existed inside the agentics pack, but ASP.NET Core hosts and /engine/snapshot could not expose the run-state catalog without depending directly on Cephalon.Agentics
• the smallest honest next proof is to promote the read contract to the host-agnostic abstraction layer, then project it through the existing operator surfaces while keeping dispatcher and report ownership in the selected agentics pack

Delivered:

• move AgentToolExecutionOutcomes, AgentToolRunState, and IAgentToolRunCatalog to Cephalon.Abstractions.Agentics
• keep Cephalon.Agentics as the implementation owner for dispatch, executor resolution, policy decisions, observer callbacks, run reporting, and the in-memory run-state catalog
• add /engine/agent-tool-runs, /engine/agent-tool-runs/{runId}, /engine/agent-tool-runs/by-tool/{toolId}, and snapshot.AgentToolRuns
• prove the managed execution route, by-tool drill-down, missing-run 404, package-surface, generated reference-doc, and docs alignment paths through focused hosting/tooling coverage - issue #775

Follow-up later:

• autonomous planning, memory persistence, retry queues, provider-specific AI orchestration, and operator automation remain future work until a package truly owns those paths

ENG-267 Retrieval knowledge-index operator-surface baseline

Status: done Estimate: 5

Why:

• after ENG-233, indexing, query execution, and freshness state existed inside the retrieval pack, but ASP.NET Core hosts and /engine/snapshot could not expose the index-state catalog without depending directly on Cephalon.Retrieval
• the smallest honest next proof is to promote the read contract to the host-agnostic abstraction layer, then project it through the existing operator surfaces while keeping indexing and query ownership in the selected retrieval pack

Delivered:

• move IKnowledgeIndexCatalog, KnowledgeIndexState, KnowledgeIndexFreshnessStates, and KnowledgeIndexingOutcomes to Cephalon.Abstractions.Retrieval
• keep Cephalon.Retrieval as the implementation owner for document-provider ingestion, managed lexical indexing, bounded query execution, freshness calculation, and the in-memory index-state catalog
• add /engine/knowledge-indexes, /engine/knowledge-indexes/{collectionId}, and snapshot.KnowledgeIndexes
• prove the indexed collection route, missing-index 404, package-surface, generated reference-doc, and docs alignment paths through focused hosting/tooling coverage - issue #776

Follow-up later:

• vector databases, embedding pipelines, durable or distributed indexes, rerankers, provider-specific semantic search, and distributed scheduler coordination remain future work until a package truly owns those paths; opt-in in-process background reindexing later shipped in ENG-270, and the bounded query operator action later shipped in ENG-283

ENG-268 Retrieval reindex operator-action baseline

Status: done Estimate: 5 Issue: #777

Why:

• after ENG-267, operators could read index state but could not remediate stale or missing index posture without referencing the retrieval implementation package
• the smallest honest action proof is a host-agnostic indexing command contract plus an ASP.NET Core manual reindex route over the existing managed lexical indexer

Delivered:

• promote IKnowledgeIndexer, KnowledgeIndexingRequest, and KnowledgeIndexingResult to Cephalon.Abstractions.Retrieval
• keep Cephalon.Retrieval as the implementation owner for provider ingestion, lexical indexing, freshness calculation, and index-state updates
• add POST /engine/knowledge-indexes/{collectionId}/reindex with generated or caller-supplied run id plus safe actor, correlation, trigger, and route metadata
• prove the successful reindex route, missing-collection 404, package-surface, generated reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• durable or distributed indexes, vector or semantic search, rerankers, provider-specific search adapters, and distributed scheduler coordination remain later package-owned work

ENG-270 Retrieval background reindex scheduler baseline

Status: done Estimate: 5 Issue: #779

Why:

• after ENG-268, operators could manually reindex stale or missing collections, but hosts still had to write their own timer if they wanted periodic freshness
• the smallest honest automation proof is an opt-in in-process scheduler over the existing IKnowledgeIndexer, not a vector store, distributed scheduler, or provider-specific search stack

Delivered:

• add RetrievalOptions.EnableBackgroundReindexing, startup-run, initial-delay, interval, and collection-scope options
• register a generic-host IHostedService only when ingestion and background reindexing are enabled
• schedule startup and repeated runs over all registered collections or the configured collection ids
• record safe scheduler metadata through KnowledgeIndexingRequest and expose retrieval.background-reindexing plus backgroundReindexing* technology-surface metadata, including per-collection scheduled/not-selected truth when hosts scope the scheduler
• prove the focused composition path with an opt-in scheduler run over a registered document provider

Follow-up later:

• durable or distributed indexes, vector or semantic search, embeddings, rerankers, provider-specific search adapters, distributed scheduler coordination, leader election, and multi-node freshness orchestration remain later package-owned work

ENG-271 Eventing in-process subscription execution baseline

Status: done Estimate: 5 Issue: #780

Why:

• after the adapter-neutral binding/readiness surfaces shipped, the core eventing pack still needed one useful managed execution lane that did not require consumer apps to install Wolverine for lightweight in-process flows
• the smallest honest proof is a direct process-local publisher over registered IEventSubscriptionExecutor services, not a durable broker, inbox, distributed dispatcher, or retry queue

Delivered:

• add EventingOptions.EnableInProcessSubscriptionExecution and ContinueInProcessSubscriptionExecutionAfterFailure
• register a Cephalon-managed direct in-process binding contributor when the option is enabled and subscription executors exist
• expose eventing.publish, eventing.subscribe, event-publishers, event-subscriptions, /engine/event-subscription-readiness, and snapshot.EventSubscriptionExecutionReadiness with cephalon-managed, in-process-direct, and retryPolicy = none metadata
• execute matching subscriptions through IEventPublisher and record started/succeeded/failed runtime observations through the existing subscription runtime catalog
• prove the host path with focused ASP.NET Core hosting coverage that publishes an event, executes a real executor, and verifies capabilities, runtime surfaces, readiness, and snapshot truth

Follow-up later:

• durable broker dispatch, inbox/idempotency ownership, retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work until a package truly owns those paths

ENG-272 Eventing publication operator action baseline

Status: done Estimate: 5 Issue: #781

Why:

• after ENG-271, the core eventing pack could execute in-process subscriptions through IEventPublisher, but host adapters and operators still lacked a bounded publication action that did not reference Cephalon.Eventing implementation types
• the smallest honest next proof is an abstraction-level publication request/result/dispatcher seam plus one ASP.NET Core route over the existing publish path, not a generic broker, inbox, durable retry, or provider-consumption story

Delivered:

• add EventPublicationOutcomes, EventPublicationRequest, EventPublicationResult, and IEventPublicationDispatcher to Cephalon.Abstractions.Data
• keep Cephalon.Eventing as the implementation owner by registering EventPublicationDispatcher over the active IEventPublisher whenever a real publishing path exists
• add POST /engine/event-publications, returning EventPublicationResult, safe trigger/route metadata, 400 for invalid bodies, and 404 for inactive publication or unknown channels
• prove the route executes the core in-process direct publisher, invokes a real IEventSubscriptionExecutor, records subscription runtime state, and exposes publicationDispatcher = available capability/runtime metadata without Wolverine

Follow-up later:

• durable broker dispatch, inbox/idempotency ownership, retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work until a package truly owns those paths

ENG-273 Eventing in-process subscription retry baseline

Status: done Estimate: 5 Issue: #782

Why:

• after ENG-272, the core in-process eventing lane could execute and publish through real operator actions, but transient executor failures still ended as a single failed attempt unless a consumer selected a provider-managed companion runtime
• the smallest honest next proof is bounded process-local retry over the existing direct IEventPublisher / IEventSubscriptionExecutor lane, not a durable broker retry queue, inbox, or distributed subscription scheduler

Delivered:

• add EventingOptions.InProcessSubscriptionMaxAttempts and InProcessSubscriptionRetryDelayMilliseconds with safe defaults that preserve retryPolicy = none
• retry failing in-process subscription executors inline up to the configured maximum attempts, reporting retry-scheduled observations before retries and final succeeded or failed runtime state through the existing subscription runtime catalog
• project retryPolicy = bounded-in-process, retryMaxAttempts, retryDelayMilliseconds, retryDurability = none, and retryScope = process-local through capabilities, managed execution bindings, event-publishers, event-subscriptions, and reported.* metadata
• prove the host path with focused ASP.NET Core hosting coverage that fails once, retries, succeeds, and verifies runtime counters plus capability/surface metadata

Follow-up later:

• durable broker dispatch, inbox/idempotency ownership, durable retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work until a package truly owns those paths

ENG-274 Eventing in-process subscription idempotency baseline

Status: done Estimate: 5 Issue: #783

Why:

• after ENG-273, the core in-process eventing lane could publish, execute, and retry transient subscription failures, but duplicate submissions of the same publication id could still re-run a successful in-process executor
• the smallest honest next proof is completed-execution duplicate suppression inside the existing process-local lane, not durable inbox ownership, cross-node exactly-once delivery, or broker deduplication

Delivered:

• add EventingOptions.EnableInProcessSubscriptionIdempotency and InProcessSubscriptionIdempotencyRetentionMinutes with safe defaults that preserve existing non-idempotent behavior
• track successful subscriptionId + publicationId executions in a bounded process-local tracker and skip duplicate completed executions during the retention window
• report duplicate suppressions as skipped observations through the subscription runtime catalog with idempotencyPolicy = completed-publication, idempotencyKey = subscription-publication, idempotencyRetentionMinutes, idempotencyDurability = none, idempotencyScope = process-local, and idempotencyOutcome = duplicate-skipped
• project the same idempotency truth through capabilities, managed execution bindings, event-publishers, event-subscriptions, and reported.* metadata
• prove the host path with focused ASP.NET Core hosting coverage that publishes the same id twice, executes the subscription once, and verifies the duplicate skip runtime state plus metadata

Follow-up later:

• durable broker dispatch, durable inbox ownership, cross-node exactly-once delivery, durable retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work until a package truly owns those paths

ENG-275 Eventing publication runtime operator-state baseline

Status: done Estimate: 5 Issue: #784

Why:

• after ENG-272 through ENG-274, operators could request a bounded publication and inspect subscription execution state, but they still lacked one typed publication-level answer for accepted, succeeded, failed, or skipped posture
• the smallest honest next proof is a host-agnostic publication runtime-state catalog over the existing publisher paths, not a durable broker-delivery or downstream dispatch-completion claim

Delivered:

• add EventPublicationRuntimeOutcomes, EventPublicationRuntimeState, and IEventPublicationRuntimeCatalog to Cephalon.Abstractions.Data
• report direct in-process publication outcomes with matched, started, succeeded, failed, retry-scheduled, and skipped subscription counts, latest error, and safe metadata
• report outbox-backed publications as accepted staged handoff with handoff = outbox and deliveryCompletion = pending-dispatch metadata instead of pretending downstream delivery completed synchronously
• expose the same state through /engine/event-publications/runtime, /engine/event-publications/runtime/{publicationId}, /engine/event-publications/runtime/channels/{channelId}, snapshot.EventPublicationStates, and event-publishers metadata
• prove the host path with focused ASP.NET Core hosting coverage for publication state, channel drill-down, snapshot projection, runtime-surface metadata, and duplicate-skip publication reporting

Follow-up later:

• durable broker dispatch, durable inbox ownership, cross-node exactly-once delivery, downstream dispatch completion, durable retry queues, distributed subscription scheduling, and provider-specific inbound consumption remain future package-owned work until a package truly owns those paths

ENG-276 Wolverine bounded subscription retry terminal failure

Status: done Estimate: 3 Issue: #785

Why:

• the optional Wolverine companion already owns a provider-managed declared-subscription execution lane, but fixed-delay retries could keep poison subscription messages cycling without one terminal runtime answer
• the smallest honest hardening proof is bounded retry for the path Wolverine actually owns, not a generic inbound broker or durable inbox claim

Delivered:

• add SubscriptionMaxAttempts to WolverineEventingOptions with a default of 3 and validation that the value stays greater than or equal to 1
• project retryPolicy = bounded-fixed-delay, retryMaxAttempts, retryDelaySeconds, retryDurability = wolverine-scheduled-message, and retryScope = provider-managed through eventing.subscribe, IEventSubscriptionExecutionBindingCatalog, event-subscriptions, and the wolverine-adapter runtime surface
• keep scheduling retries through Wolverine’s scheduled-message pipeline while attempts remain available, then report terminal failed runtime state with retryExhausted = true and terminalFailure = true when the max-attempt budget is exhausted
• prove both the retry-then-success path and the terminal-exhausted path with focused composition coverage, and prove the ASP.NET Core operator metadata through focused hosting coverage

Follow-up later:

• broader inbound broker-consumption ownership, durable inbox ownership, and dispatch-loop dead-letter semantics remain future package-owned work until a package truly owns those paths

ENG-277 Wolverine dispatch terminal retry failure

Status: done Estimate: 3 Issue: #786

Why:

• the optional Wolverine companion already owns a provider-managed staged dispatch loop, but no-destination or publish failures could keep poison staged publications re-entering pending dispatch forever
• the smallest honest hardening proof is bounded retry for the dispatch loop Wolverine actually owns, not a generic broker dead-letter, inbox, or inbound-consumption claim

Delivered:

• add DispatchMaxAttempts to WolverineEventingOptions with a default of 3 and validation that the value stays greater than or equal to 1
• project retryPolicy = bounded-fixed-delay, retryMaxAttempts, retryDelaySeconds, retryDurability = dispatch-store-delayed-eligibility, and retryScope = provider-managed through eventing.wolverine.dispatch, dispatch runtime descriptors, dispatch reports, and the wolverine-adapter runtime surface
• report terminal failed dispatch observations with retryOutcome = max-attempts-exhausted, retryExhausted = true, and terminalFailure = true when the max-attempt budget is exhausted
• add stable EventDispatchRuntimeMetadataKeys and teach the supported dispatch stores to stop terminal failed messages from re-entering pending-dispatch reads
• prove the retry-scheduled path, terminal exhausted path, Entity Framework dispatch-store terminal behavior, ASP.NET Core operator metadata, package surface, and reference-doc alignment through focused coverage

Follow-up later:

• broader inbound broker-consumption ownership, durable inbox ownership, broker-specific dead-letter queues, provider-specific dead-letter storage, and cross-node exactly-once delivery remain future package-owned work until a package truly owns those paths

ENG-278 Wolverine dispatch publish-exception terminal proof

Status: done Estimate: 2 Issue: #787

Why:

• ENG-277 made the Wolverine-managed dispatch loop bounded for both no-destination and publish-failure paths, but the exact IMessageBus.PublishAsync(...) exception branch needed focused proof so the docs did not rely on an inferred failure mode
• the smallest honest follow-through is test-backed runtime proof for the publish-exception path, not a new generic dead-letter queue, inbox, or broker-consumption claim

Delivered:

• prove that when Wolverine has destinations but PublishAsync(...) throws before the max-attempt budget is exhausted, the dispatch loop reports retry-scheduled with routing = publish, exceptionType, nextRetryAtUtc, and bounded fixed-delay metadata
• prove that when the same publish exception occurs on the final attempt, the dispatch loop reports terminal failed state with retryOutcome = max-attempts-exhausted, retryExhausted = true, terminalFailure = true, routing = publish, and no nextRetryAtUtc
• prove the terminal publish-failure report removes the staged publication from pending-dispatch reads through the same EventDispatchRuntimeMetadataKeys terminal metadata contract

Follow-up later:

• broker-specific dead-letter queues, durable inbox ownership, generic inbound broker consumption, and cross-node exactly-once delivery remain future package-owned work until a package truly owns those paths

ENG-279 First-class event-dispatch terminal-failure runtime posture

Status: done Estimate: 2 Issue: #788

Why:

• ENG-277 and ENG-278 proved terminal dispatch metadata and dispatch-store behavior, but operators still had to parse reported.* metadata to find terminally failed outbox paths from the generic runtime surfaces
• the smallest honest follow-through is a first-class operator read posture over the existing dispatch-state catalog, not a new broker-specific dead-letter queue or durable inbox claim

Delivered:

• add EventDispatchRuntimeState.TerminalFailure plus TerminalFailureCount so per-outbox dispatch state reports the latest terminal posture and terminal observation count directly
• add EventDispatchRuntimeSummary.TerminalFailureCount, TerminalOutboxCount, and HasTerminalFailures so /engine/event-dispatch-runtimes and snapshot.EventDispatchRuntimes expose aggregate terminal posture without re-aggregating metadata
• add /engine/event-dispatches/terminal-failures plus event-dispatches / event-dispatch-runtimes technology-surface metadata so operator tooling can drill into exhausted dispatch paths without parsing reported.*

Follow-up later:

• broker-specific dead-letter queues, durable inbox ownership, generic inbound broker consumption, downstream delivery completion, and cross-node exactly-once delivery remain future package-owned work until a package truly owns those paths

ENG-269 Agentics tool execution operator-action baseline

Status: done Estimate: 5 Issue: #778

Why:

• after ENG-266, operators could read agent-tool run state but could not trigger one managed run through a host adapter without referencing the agentics implementation package
• the smallest honest action proof is a host-agnostic dispatcher request/result contract plus an ASP.NET Core route over the existing managed tool dispatcher

Delivered:

• promote IAgentToolDispatcher, AgentToolExecutionRequest, and AgentToolExecutionResult to Cephalon.Abstractions.Agentics
• keep Cephalon.Agentics as the implementation owner for descriptor resolution, executor invocation, policy decisions, observer notifications, and run-state reporting
• add POST /engine/agent-tools/{toolId}/runs with generated or caller-supplied run id plus safe actor, correlation, attempt, argument, trigger, and route metadata
• prove the successful operator route, missing-tool 404, package-surface, generated reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• autonomous planning, memory persistence, durable retry queues, provider-specific AI orchestration, and broader agent operator workflows remain later package-owned work

ENG-280 Agentics bounded in-process retry posture

Status: done Estimate: 3 Issue: #789

Why:

• after ENG-269, Agentics could execute one bounded operator-triggered tool run, but transient executor failures still moved straight to final failure unless the consumer app owned its own retry loop
• the smallest honest follow-through is bounded process-local retry inside the dispatcher lane that Cephalon already owns, not a durable retry queue, memory store, autonomous planner, or provider-specific AI orchestration claim

Delivered:

• add AgenticRuntimeOptions.ExecutionMaxAttempts and ExecutionRetryDelayMilliseconds with defaults that preserve single-attempt execution
• add retry-scheduled agent-tool observations plus RetryScheduledCount and RetryPending run-state posture so operators can see process-local retry waits directly
• project retry policy, max attempts, delay, durability, scope, retry counters, and retry-pending posture through agentics.execution, agent-tools, /engine/agent-tool-runs/retry-pending, and snapshot.AgentToolRuns

Follow-up later:

• durable retry queues, autonomous planning, memory persistence, distributed scheduling, provider-specific AI orchestration, and broader agent operator workflows remain future package-owned work until a package truly owns those paths

ENG-281 Agentics process-local duplicate-run idempotency posture

Status: done Estimate: 3 Issue: #790

Why:

• after ENG-280, Agentics could retry transient executor failures inside the bounded dispatcher lane, but duplicate operator/client requests with the same completed run id still reached the executor unless the consumer app owned its own guard
• the smallest honest follow-through is opt-in process-local duplicate-completed suppression over the run-state catalog Cephalon already owns, not a durable inbox, distributed exactly-once layer, autonomous planner, or provider-specific AI orchestration claim

Delivered:

• add AgenticRuntimeOptions.EnableExecutionIdempotency and ExecutionIdempotencyRetentionMinutes with defaults that preserve repeated execution behavior
• suppress duplicate completed toolId + runId executions inside the configured process-local retention window, report the duplicate as skipped, and expose DuplicateCompleted on AgentToolRunState
• project idempotency policy, key, retention, durability, scope, duplicate outcome, and duplicate-completed posture through agentics.execution, agent-tools, /engine/agent-tool-runs/idempotency-duplicates, and snapshot.AgentToolRuns

Follow-up later:

• durable inboxes, cross-node exactly-once delivery, durable retry queues, autonomous planning, memory persistence, distributed scheduling, provider-specific AI orchestration, and broader agent operator workflows remain future package-owned work until a package truly owns those paths

ENG-282 Agentics approval-required and terminal-failure operator posture

Status: done Estimate: 3 Issue: #791

Why:

• after ENG-280 and ENG-281, Agentics had real bounded retry and process-local duplicate-run posture, but operators still needed direct filters for approval-blocked and terminal-failed runs
• the smallest honest follow-through is a read-only operator seam over the existing run catalog, not a durable approval workflow, dead-letter system, autonomous planner, or provider-specific AI orchestration claim

Delivered:

• add AgentToolRunState.TerminalFailure so terminal failed tool runs are typed instead of being inferred only from LastOutcome
• expose /engine/agent-tool-runs/approval-required and /engine/agent-tool-runs/terminal-failures over the same abstraction-level run catalog
• project terminalFailure through the agent-tools runtime surface and prove approval-required plus terminal failed routes with focused composition and hosting coverage

Follow-up later:

• durable approval workflows, dead-letter systems, durable retry queues, durable inboxes, cross-node exactly-once delivery, autonomous planning, memory persistence, distributed scheduling, provider-specific AI orchestration, and broader agent operator workflows remain future package-owned work until a package truly owns those paths

ENG-283 Retrieval query operator action seam

Status: done Estimate: 3 Issue: #792

Why:

• after ENG-267, ENG-268, and ENG-270, operators could read, remediate, and schedule retrieval indexes, but a host adapter still could not execute one bounded query without referencing the retrieval implementation package
• the smallest honest action proof is a host-agnostic query request/result contract plus an ASP.NET Core route over the existing managed lexical query engine, not a vector database, embedding pipeline, reranker, durable search cluster, or semantic provider adapter claim

Delivered:

• promote IKnowledgeQueryEngine, KnowledgeQueryRequest, KnowledgeQueryResult, and KnowledgeQueryMatch to Cephalon.Abstractions.Retrieval
• keep Cephalon.Retrieval as the implementation owner for bounded lexical query execution, query result ranking, and runtime query observations
• add POST /engine/knowledge-indexes/{collectionId}/queries with safe actor, correlation, trigger, route, and metadata flow into the same index-state catalog while runtime introspection records query fingerprint and length instead of raw query text
• prove the successful query route, missing-collection 404, invalid-query 400, package-surface, and docs alignment paths through focused hosting/composition/tooling coverage

Follow-up later:

• vector databases, embedding pipelines, durable or distributed indexes, rerankers, provider-specific semantic search, distributed scheduler coordination, leader election, and multi-node freshness or search orchestration remain later package-owned work until a package truly owns those paths

ENG-284 Multi-tenancy invitation delivery status callback endpoint baseline

Status: done Estimate: 3 Issue: #793

Why:

• after ENG-261, the governance core could reconcile provider or receiver delivery status observations, but ASP.NET Core hosts still needed to hand-write normalized callback ingress before provider or adapter observations could reach the reconciler
• the smallest honest follow-through is a fail-closed generic ASP.NET Core endpoint over the existing reconciler, not provider-specific webhook payload translation, provider signature verification, provider polling, or durable notification queues

Delivered:

• add TenantInvitationDeliveryStatusCallbackRequest and MapCephalonTenantInvitationDeliveryStatusCallbacks() to Cephalon.MultiTenancy.Governance.AspNetCore
• keep the endpoint authorization fail-closed by default, enforce provider-message matching by default, and record safe callback ingress metadata before calling ITenantInvitationDeliveryStatusReconciler
• publish the tenant-invitation-delivery-status-http-endpoints runtime surface with route, method, mapped/configured/disabled state, authorization posture, provider-message-match posture, and explicit application-managed boundaries for provider-specific translation, signature verification, and polling
• prove successful callback reconciliation, anonymous denial, package-surface, reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• provider-specific email/SMS/chat/CRM/identity-provider invitation senders, provider-specific callback payload translation, provider-specific callback signature verification, provider polling, durable notification queues, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed/provider-backed governance stores, and broader provider mutation remain future governance slices until a package truly owns those paths

ENG-285 Multi-tenancy invitation delivery status callback signature verification baseline

Status: done Estimate: 3 Issue: #800

Why:

• after ENG-284, ASP.NET Core hosts had a generic normalized callback endpoint, but signed provider-adapter ingress still required consumer code before the reconciler could trust the normalized body
• the smallest honest security follow-through is provider-neutral HMAC verification over the exact normalized JSON request body, not provider-specific payload translation or provider-specific signature semantics

Delivered:

• add TenantInvitationDeliveryStatusCallbackSigningSecret, callback signature header, timestamp header, optional key-id header, signing key id, and timestamp tolerance options to MultiTenancyGovernanceAspNetCoreOptions
• verify v1=<hex-hmac-sha256> signatures over {unixTimestamp}.{exactUtf8JsonBody} before JSON parsing or reconciliation when a signing secret is configured
• fail unsigned, stale, malformed, wrong-key, or invalid signatures with 401 before ITenantInvitationDeliveryStatusReconciler mutates invitation state
• record safe verified-signature metadata on reconciled status observations without exposing secrets or signature values
• extend tenant-invitation-delivery-status-http-endpoints runtime metadata with signature verification configuration, safe header names, key-id configuration, and timestamp tolerance
• prove signed callback success, unsigned configured-callback denial, anonymous denial, package-surface, reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• provider-specific callback payload translation, provider-specific callback signature verification, provider polling, durable notification queues, provider-specific invitation senders, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-286 Multi-tenancy invitation delivery status callback replay protection baseline

Status: done Estimate: 3 Issue: #801

Why:

• after ENG-285, the ASP.NET Core normalized callback endpoint could authenticate signed bodies before reconciliation, but the same valid signed request could still be replayed inside the timestamp tolerance window unless consumer code supplied its own guard
• the smallest honest hardening step is bounded process-local duplicate signed-callback rejection, not a durable inbox, cross-node exactly-once claim, provider-specific callback translation, or provider polling loop

Delivered:

• add EnableTenantInvitationDeliveryStatusCallbackReplayProtection, TenantInvitationDeliveryStatusCallbackReplayRetentionSeconds, and TenantInvitationDeliveryStatusCallbackReplayCacheLimit to MultiTenancyGovernanceAspNetCoreOptions
• record safe SHA-256 signature fingerprints for accepted signed normalized callbacks and reject duplicate signed requests with 409 before ITenantInvitationDeliveryStatusReconciler mutates invitation state
• publish replay protection configuration, ownership, policy, key shape, process-local scope, non-durable posture, retention seconds, and cache limit through tenant-invitation-delivery-status-http-endpoints
• record safe replay metadata on reconciled observations without exposing raw signatures or secrets
• prove signed replay rejection, signed callback success, unsigned configured-callback denial, package-surface, reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• provider-specific or distributed callback inboxes, cross-node callback replay protection, provider-specific callback payload translation, provider-specific callback signature verification, provider polling, provider-specific invitation senders, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-287 Multi-tenancy invitation delivery status observation store baseline

Status: done Estimate: 3 Issue: #802

Why:

• after ENG-261 through ENG-286, Cephalon could reconcile normalized provider or receiver delivery-status observations and ASP.NET Core could protect normalized signed callback ingress, but operators still had to infer observation history from the mutable invitation metadata alone
• the smallest honest core follow-through is a normalized observation store over the reconciler’s accepted or denied outcomes, not a provider-specific callback inbox, provider polling loop, distributed replay guard, or exactly-once delivery claim

Delivered:

• add ITenantInvitationDeliveryStatusObservationStore and TenantInvitationDeliveryStatusObservationDescriptor to record stable normalized observation ids, status, reconciliation outcome, timestamps, provider message id, sender, channel, source, actor, correlation, reason, and safe metadata
• add an in-memory default store plus opt-in local JSON durability through MultiTenancyGovernanceOptions.InvitationDeliveryStatusObservationStoreFilePath
• add EnableInvitationDeliveryStatusObservationStore and InvitationDeliveryStatusObservationHistoryLimit so hosts can disable or bound the normalized observation history deliberately
• publish tenancy.invitation.delivery-status-observation-store capability metadata plus tenant-invitations runtime metadata for store kind, durability, scope, history limit, count, and latest observation
• record observation-store metadata on reconciliation results and invitation metadata without blocking reconciliation if the observation store fails
• prove in-memory observation storage, file-backed restart persistence, mismatch recording, ASP.NET Core callback ingestion, replay suppression interaction, package-surface, reference-doc, and docs alignment paths through focused coverage

Follow-up later:

• provider-specific or distributed callback inboxes, cross-node callback replay protection, provider-specific callback payload translation, provider-specific callback signature verification, provider polling, provider-specific invitation senders, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-288 Multi-tenancy invitation delivery status observation endpoint baseline

Status: done Estimate: 3 Issue: #803

Why:

• after ENG-287, the governance core retained normalized delivery-status observations, but ASP.NET Core hosts still needed custom glue to read that history over HTTP
• the smallest honest host-adapter follow-through is a bounded operator/audit read endpoint over the existing observation store, not a provider-specific callback inbox, provider polling loop, distributed replay ledger, or exactly-once delivery claim

Delivered:

• add MapCephalonTenantInvitationDeliveryStatusObservations() for GET /engine/tenant-invitations/delivery-status/observations
• add TenantInvitationDeliveryStatusObservationQueryResult with observation-store kind, durability, ownership, total/matched/returned counts, effective limit, normalized filters, and bounded observation records
• keep observation reads fail-closed by default through RequireTenantInvitationDeliveryStatusObservationAuthorization and optional policy configuration
• support bounded filters for tenant id, invitation id, status, outcome, source, correlation id, reconciled, recorded, and limit, with TenantInvitationDeliveryStatusObservationMaxLimit clamping the response size
• extend tenant-invitation-delivery-status-http-endpoints with observation read route, method, response contract, authorization posture, default/max limits, and provider-specific callback inbox boundary truth
• prove callback-created observation reads, anonymous denial, package-surface, reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• provider-specific or distributed callback inboxes, cross-node callback replay protection, provider-specific callback payload translation, provider-specific callback signature verification, provider polling, provider-specific invitation senders, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-289 Multi-tenancy invitation delivery dispatch endpoint baseline

Status: done Estimate: 3 Issue: #804

Why:

• after ENG-256 and the HTTP sender follow-through, the governance core could dispatch invitations through registered sender extensions, but ASP.NET Core hosts still needed custom glue to invoke that dispatcher over HTTP
• the smallest honest host-adapter proof is a fail-closed action endpoint over the existing dispatcher, not provider-specific sender ownership, durable retry queues, public onboarding, tenant-admin UI, identity-provider synchronization, or provider polling

Delivered:

• add MapCephalonTenantInvitationDeliveryDispatches() for POST /engine/tenant-invitations/delivery-dispatches
• keep dispatch authorization fail-closed by default through RequireTenantInvitationDeliveryDispatchAuthorization and optional policy configuration
• route requests through ITenantInvitationDeliveryDispatcher, default the dispatch source to aspnetcore-invitation-delivery-dispatch, and record safe adapter metadata on the invitation
• map dispatcher outcomes to explicit HTTP status codes for dispatched, not-found, conflict, unavailable, and invalid-request postures
• add the tenant-invitation-delivery-http-endpoints runtime surface with route, method, request/result contract, authorization posture, status mapping, and boundary metadata
• prove successful dispatch, default anonymous denial, package-surface, reference-doc, and docs alignment paths through focused hosting/tooling coverage

Follow-up later:

• provider-specific email/SMS/chat/CRM/identity-provider invitation senders, automatic background retry scheduling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, provider polling, provider-specific callback inboxes, distributed retry queues, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-290 Multi-tenancy invitation delivery durable retry queue baseline

Status: done Estimate: 3 Issue: #805

Why:

• after ENG-289, hosts could invoke the core dispatch path over HTTP, but retryable sender failures still required consumer apps to invent their own queue if they wanted retry evidence to survive beyond the immediate run catalog
• the smallest honest proof is an opt-in local retry store plus bounded manual runner over the host-agnostic dispatcher, not automatic background scheduling, distributed queue ownership, provider-specific sender ownership, public onboarding, tenant-admin UI, or exactly-once delivery

Delivered:

• add public ITenantInvitationDeliveryRetryStore, ITenantInvitationDeliveryRetryRunner, retry descriptor/request/result contracts, retry statuses/outcomes, and retry metadata keys
• queue retryable sender-failed dispatch outcomes when EnableInvitationDeliveryRetryQueue is enabled, preserving tenant/invitation/channel/sender boundary, attempts, max attempts, next-attempt timestamp, latest outcome/reason, and ownership metadata
• provide an in-memory default and opt-in local JSON durability through InvitationDeliveryRetryQueueFilePath
• add bounded manual RetryPendingAsync(...) execution over pending due entries, delegating each attempt through ITenantInvitationDeliveryDispatcher and clearing successful retries
• expose tenancy.invitation.delivery-retry-queue plus tenant-invitations retry queue enablement, store kind/durability/scope/counts, latest retry outcome, and retry policy metadata
• prove queueing, bounded retry success/clear, local JSON persistence, package surface, and reference-doc alignment through focused composition/tooling coverage

Follow-up later:

• distributed retry queues, cross-node retry leases, exactly-once delivery, provider-specific email/SMS/chat/CRM/identity-provider senders, provider-specific callback inboxes, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-291 Multi-tenancy invitation delivery background retry scheduling baseline

Status: done Estimate: 3 Issue: #806

Why:

• after ENG-290, the governance core could persist retryable sender failures and replay them through a bounded runner, but consumer apps still had to schedule recurring retry execution themselves
• the smallest honest automation proof is an opt-in generic-host background service over the existing bounded runner, not a distributed queue, cross-node lease, exactly-once delivery guarantee, provider-specific invitation sender, public onboarding flow, tenant-admin UI, identity-provider sync, provider polling loop, provider callback inbox, or distributed/provider-backed governance store

Delivered:

• add EnableInvitationDeliveryRetryBackgroundScheduling, InvitationDeliveryRetryBackgroundIntervalSeconds, InvitationDeliveryRetryBackgroundRunOnStartup, and InvitationDeliveryRetryBackgroundSource to MultiTenancyGovernanceOptions
• register TenantInvitationDeliveryRetryHostedService only when both the retry queue and background scheduling are enabled, then run ITenantInvitationDeliveryRetryRunner.RetryPendingAsync(...) on startup and on the configured interval with the existing bounded max-item policy
• add ITenantInvitationDeliveryRetryRuntimeCatalog and TenantInvitationDeliveryRetryRuntimeSnapshot so operators can read enabled state, ownership, interval, startup behavior, latest run outcome, counts, timestamps, and errors
• expose tenancy.invitation.delivery-retry-background-scheduling, diagnostics events 4554-4557, and tenant-invitations deliveryRetryBackground* metadata without claiming distributed retry ownership
• prove startup scheduling, retry clearing, runtime reporting, capability metadata, package surface, and reference-doc alignment through focused composition/tooling coverage

Follow-up later:

• distributed retry queues, cross-node retry leases, exactly-once delivery, provider-specific email/SMS/chat/CRM/identity-provider senders, provider-specific callback inboxes, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-292 Multi-tenancy invitation delivery retry execution coordination baseline

Status: done Estimate: 3 Issue: #807

Why:

• after ENG-291, manual retry passes and the opt-in background scheduler could both invoke the same bounded retry runner inside one host process, so retry behavior was real but same-process overlap still depended on consumer discipline
• the smallest honest coordination proof is a process-local skip-overlap guard with runtime introspection, not distributed queue ownership, cross-node leases, exactly-once delivery, provider-specific sender ownership, public onboarding, tenant-admin UI, identity-provider sync, provider polling, provider callback inboxes, or distributed/provider-backed governance stores

Delivered:

• add EnableInvitationDeliveryRetryExecutionCoordination to MultiTenancyGovernanceOptions, enabled by default when the retry runner is effectively enabled
• add ITenantInvitationDeliveryRetryExecutionCoordinationCatalog and TenantInvitationDeliveryRetryExecutionCoordinationSnapshot so operators can read enabled state, ownership, process-local scope, skip-overlap mode, in-progress state, accepted/skipped/completed counts, latest timestamps, latest outcome, and latest error
• wrap ITenantInvitationDeliveryRetryRunner.RetryPendingAsync(...) with a process-local gate; an overlapping pass returns the stable already-running retry outcome without dispatching entries or mutating the retry queue
• expose tenancy.invitation.delivery-retry-execution-coordination, retry result metadata keys, and tenant-invitations deliveryRetryExecutionCoordination* metadata while keeping distributed retry ownership explicitly application-managed
• prove concurrent manual retry skip behavior, runtime/capability metadata, package surface, and reference-doc alignment through focused composition/tooling coverage

Follow-up later:

• distributed retry queues, cross-node retry leases, exactly-once delivery, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, provider-specific callback inboxes, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths; SMTP relay handoff is covered by ENG-293 and SendGrid Mail Send API handoff is covered by ENG-294; Mailgun Messages API handoff is covered by ENG-299

ENG-293 Multi-tenancy invitation delivery SMTP sender baseline

Status: done Estimate: 5 Issue: #808

Why:

• after ENG-292, Cephalon could dispatch invitations, persist outcomes, queue retryable sender failures, schedule retries, and prevent same-process retry overlap, but the first-party delivery options were still generic HTTP webhook or consumer-written senders
• the smallest honest provider-managed sender proof is SMTP relay handoff: it sends a prepared email through a configured relay without claiming transactional-email provider APIs, bounce handling, provider callback translation, public onboarding, or identity-provider synchronization

Delivered:

• add Cephalon.MultiTenancy.Governance.SmtpDelivery as an optional companion package with configuration/code-first registration through AddCephalonSmtpInvitationDelivery(...)
• add SmtpInvitationDeliveryOptions for relay host, port, TLS, credentials, from address, recipient metadata key, supported channels, templates, message-id domain, safe context headers, and timeout
• add ISmtpInvitationDeliveryClient, SmtpInvitationDeliveryMessage, and SmtpInvitationDeliveryClientResult so hosts can test or replace the SMTP relay client without changing the core governance dispatcher
• implement the smtp-email ITenantInvitationDeliverySender with recipient resolution from dispatch metadata, invitation metadata, or InviteeKind = email, deterministic SMTP Message-Id generation, safe context headers, safe sender metadata, and dispatched / suppressed / sender-failed outcomes over the existing dispatcher
• publish Cephalon.MultiTenancy.Governance.SmtpDelivery diagnostics 4558-4559, package-surface coverage, component docs, operations guidance, compatibility truth, maturity-audit ownership, and reference-doc alignment

Follow-up later:

• provider-specific email API connectors beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, bounce/callback translation, provider polling, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths; SendGrid Mail Send API handoff is covered by ENG-294 and Mailgun Messages API handoff is covered by ENG-299

ENG-294 Multi-tenancy invitation delivery SendGrid sender baseline

Status: done Estimate: 5 Issue: #809

Why:

• after ENG-293, Cephalon could dispatch invitations through generic HTTP webhooks or SMTP relay handoff, but SendGrid teams still had to implement Mail Send API payload construction, authentication, sandbox validation, and safe provider message-id capture themselves
• the smallest honest provider-specific email proof is SendGrid Mail Send API handoff over the existing ITenantInvitationDeliverySender seam, not SendGrid Event Webhook ingestion, bounce handling, provider polling, dynamic template lifecycle management, or broader onboarding flows

Delivered:

• add Cephalon.MultiTenancy.Governance.SendGridDelivery as an optional companion package with configuration/code-first registration through AddCephalonSendGridInvitationDelivery(...)
• add SendGridInvitationDeliveryOptions for base URL, API key, from address, recipient metadata key, supported channels, subject/text/HTML templates, headers, categories, custom arguments, sandbox mode, provider message-id header name, accepted status codes, and timeout
• add ISendGridInvitationDeliveryClient, SendGridInvitationDeliveryMessage, and SendGridInvitationDeliveryClientResult so hosts can test or replace the SendGrid HTTP client without changing the core governance dispatcher
• implement the sendgrid-email ITenantInvitationDeliverySender with recipient resolution from dispatch metadata, invitation metadata, or InviteeKind = email, deterministic Cephalon message ids carried through safe custom arguments and headers, templated Mail Send payload construction, SendGrid X-Message-ID capture, safe sender metadata, and dispatched / suppressed / sender-failed outcomes over the existing dispatcher
• publish Cephalon.MultiTenancy.Governance.SendGridDelivery diagnostics 4560-4561, package-surface coverage, component docs, operations guidance, compatibility truth, maturity-audit ownership, and reference-doc alignment

Follow-up later:

• SendGrid webhook signature verification, durable callback inboxes, distributed replay protection, bounce handling, provider polling, dynamic-template lifecycle management, additional provider-specific email API 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 synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths; Mailgun Messages API handoff is covered by ENG-299

ENG-295 Multi-tenancy invitation delivery SendGrid Event Webhook callback translation baseline

Status: done Estimate: 5 Issue: #810

Why:

• after ENG-294, Cephalon could send tenant invitations through SendGrid and record SendGrid X-Message-ID, but ASP.NET Core hosts still needed custom glue to translate SendGrid Event Webhook arrays back into the existing delivery-status reconciler
• the smallest honest follow-through is a provider-specific callback translator over the existing reconciler, not SendGrid signed-webhook verification, durable callback inbox ownership, distributed replay protection, provider polling, or dynamic-template lifecycle management

Delivered:

• add Cephalon.MultiTenancy.Governance.SendGridDelivery.AspNetCore as an optional ASP.NET Core companion package with configuration/code-first registration through AddCephalonSendGridInvitationDeliveryAspNetCore(...)
• add SendGridInvitationDeliveryAspNetCoreOptions for route, authorization, endpoint-description posture, provider-message matching, status recording, source/actor, body/event limits, engagement-event mapping, and sg_message_id normalization
• add MapCephalonSendGridInvitationDeliveryStatusCallbacks() for fail-closed POST /engine/tenant-invitations/delivery-status/sendgrid callback translation
• translate SendGrid Event Webhook arrays with Cephalon custom arguments, sg_event_id, sg_message_id, event type, timestamp, reason, and bounce/suppression context into TenantInvitationDeliveryStatusReconciliationRequest
• map processed, delivered, deferred, bounce, dropped, spamreport, unsubscribe, and group_unsubscribe into normalized delivery statuses while skipping engagement events by default
• publish tenant-invitation-delivery-sendgrid-status-callbacks, diagnostics 4562, package-surface coverage, component docs, operations guidance, compatibility truth, maturity-audit ownership, and reference-doc alignment

Follow-up later:

• durable callback inboxes, distributed replay protection, cross-node exactly-once claims, provider polling, dynamic-template lifecycle management, non-SendGrid provider-specific callback translation and signature verification, additional provider-specific email API 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 synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-296 Multi-tenancy invitation delivery SendGrid signed Event Webhook verification

Status: done Estimate: 5 Issue: #811

Why:

• after ENG-295, Cephalon could translate SendGrid Event Webhook arrays, but production hosts still needed custom glue or gateway policy to verify SendGrid’s signed Event Webhook before reconciliation
• the narrow owned proof is ECDSA-SHA256 verification over SendGrid’s timestamp plus raw request body bytes, not a durable callback inbox, cross-node replay ledger, OAuth authority, or provider poller

Delivered:

• add RequireSignedEventWebhook, SignedEventWebhookPublicKey, configurable SendGrid signature and timestamp headers, and timestamp tolerance options to SendGridInvitationDeliveryAspNetCoreOptions
• verify X-Twilio-Email-Event-Webhook-Signature and X-Twilio-Email-Event-Webhook-Timestamp with ECDSA-SHA256 over timestamp + rawBody before JSON parsing or reconciliation
• fail closed for missing, malformed, stale, or invalid signatures before touching invitation state or delivery-status observations; public-key misconfiguration returns an operator-facing server error
• add safe callback result fields and reconciliation metadata for signature verification outcome, algorithm, payload shape, timestamp, age, and signature fingerprint without storing the public key, raw signature, recipient email, or raw payload
• project signed-webhook posture through tenant-invitation-delivery-sendgrid-status-callbacks and add diagnostics 4563 for rejected signed-webhook verification attempts
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, and focused hosting coverage

Follow-up later:

• durable callback inboxes, distributed replay protection, cross-node exactly-once claims, provider polling, dynamic-template lifecycle management, non-SendGrid provider-specific callback translation and signature verification, additional provider-specific email API 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 synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-297 Multi-tenancy invitation delivery SendGrid signed Event Webhook replay protection baseline

Status: done Estimate: 3 Issue: #812

Why:

• after ENG-296, Cephalon could verify SendGrid signed Event Webhook callbacks before parsing or reconciliation, but duplicate verified signed requests inside one host process still needed a first-party guard instead of host-specific glue or gateway-only policy
• the narrow owned proof is bounded process-local replay rejection over verified SendGrid signature fingerprints, not a durable callback inbox, cross-node replay ledger, provider poller, or exactly-once delivery claim

Delivered:

• add EnableSignedEventWebhookReplayProtection, SignedEventWebhookReplayRetentionSeconds, and SignedEventWebhookReplayCacheLimit to SendGridInvitationDeliveryAspNetCoreOptions
• record verified signed Event Webhook signature fingerprints in a bounded process-local cache and reject duplicates with 409 before reconciliation
• add safe callback result fields and reconciliation metadata for replay outcome, ownership, policy, key, scope, durability, retention, cache limit, and replay fingerprint without storing raw payloads or recipient email addresses
• project replay posture through tenant-invitation-delivery-sendgrid-status-callbacks and add diagnostic 4564 for rejected duplicate signed callbacks
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, and focused hosting coverage

Follow-up later:

• durable callback inboxes, distributed replay protection, cross-node exactly-once claims, provider polling, dynamic-template lifecycle management, non-SendGrid provider-specific callback translation and signature verification, additional provider-specific email API 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 synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-298 Multi-tenancy invitation delivery SendGrid event-id idempotency baseline

Status: done Estimate: 3 Issue: #813

Why:

• after ENG-297, Cephalon could reject duplicate signed callback requests by signature fingerprint, but SendGrid/provider retries can legitimately carry the same sg_event_id with a fresh timestamp and signature
• the narrow owned proof is observation-store-backed event-id duplicate suppression over sendgrid:{sg_event_id}, not a durable raw callback inbox, distributed event ledger, provider poller, or exactly-once delivery claim

Delivered:

• add EnableEventWebhookEventIdIdempotency to SendGridInvitationDeliveryAspNetCoreOptions
• skip duplicate translated SendGrid events before invoking ITenantInvitationDeliveryStatusReconciler when the normalized observation id already exists in ITenantInvitationDeliveryStatusObservationStore
• add DuplicateEvents, per-event duplicate-skipped results, safe reconciliation metadata, and runtime metadata for event-id idempotency outcome, ownership, policy, key, scope, store kind, and durability without storing raw payloads, raw signatures, or recipient email addresses
• project event-id idempotency posture through tenant-invitation-delivery-sendgrid-status-callbacks and add diagnostic 4565 for duplicate event-id skips
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, and focused hosting coverage

Follow-up later:

• durable callback inboxes, distributed replay protection, distributed event-id ledgers, cross-node exactly-once claims, provider polling, dynamic-template lifecycle management, non-SendGrid provider-specific callback translation and signature verification, additional provider-specific email API 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 synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths; Mailgun Messages API handoff is covered by ENG-299

ENG-299 Multi-tenancy invitation delivery Mailgun sender baseline

Status: done Estimate: 5 Issue: #814

Why:

• after ENG-298, Cephalon had generic HTTP, SMTP, SendGrid outbound, and SendGrid callback truth, but Mailgun teams still had to implement Messages API payload construction, authentication, test mode, and safe provider message-id capture themselves
• the smallest honest provider-specific email proof is Mailgun Messages API handoff over the existing ITenantInvitationDeliverySender seam, not Mailgun webhook callback translation, provider polling, durable callback inboxes, or broader onboarding flows

Delivered:

• add Cephalon.MultiTenancy.Governance.MailgunDelivery as an optional companion package with configuration/code-first registration through AddCephalonMailgunInvitationDelivery(...)
• add MailgunInvitationDeliveryOptions for base URL, domain, API key, from address, recipient metadata key, supported channels, templates, tags, user variables, safe headers, test mode, provider message-id JSON property, accepted status codes, and timeout
• add IMailgunInvitationDeliveryClient, MailgunInvitationDeliveryMessage, and MailgunInvitationDeliveryClientResult so hosts can test or replace the Mailgun HTTP client without changing the core governance dispatcher
• implement the mailgun-email ITenantInvitationDeliverySender with recipient resolution from dispatch metadata, invitation metadata, or InviteeKind = email, multipart Messages API payloads, Mailgun basic auth, deterministic Cephalon message ids carried through safe v:* variables and h:* headers, Mailgun JSON id capture, safe sender metadata, and dispatched / suppressed / sender-failed outcomes over the existing dispatcher
• publish Cephalon.MultiTenancy.Governance.MailgunDelivery diagnostics 4566-4567, package-surface coverage, component docs, operations guidance, compatibility truth, maturity-audit ownership, and reference-doc alignment

Follow-up later:

• Mailgun webhook callback translation is covered by ENG-300; Mailgun HMAC signed-webhook verification is covered by ENG-301; replay-token rejection is covered by ENG-302; observation-store-backed event-id idempotency is covered by ENG-303; Microsoft Graph sendMail handoff is covered by ENG-304; Microsoft Graph Azure Identity token acquisition is covered by ENG-305; Amazon SES v2 handoff is covered by ENG-306; additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, provider polling, durable/distributed callback inboxes, distributed replay/event-id ledgers, public onboarding, tenant-admin UI/backoffice, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-300 Multi-tenancy invitation delivery Mailgun webhook callback translation baseline

Status: done Estimate: 5 Issue: #815

Why:

• after ENG-299, Cephalon could send tenant invitations through Mailgun, but consumer hosts still had to hand-write Mailgun webhook parsing, Cephalon user-variable extraction, and status mapping before they could reuse the existing delivery-status reconciler
• the smallest honest follow-through was Mailgun payload translation into the existing ITenantInvitationDeliveryStatusReconciler, not durable callback inboxes, distributed replay, provider polling, or exactly-once delivery

Delivered:

• add Cephalon.MultiTenancy.Governance.MailgunDelivery.AspNetCore as an optional ASP.NET Core companion package with configuration/code-first registration through AddCephalonMailgunInvitationDeliveryAspNetCore(...)
• map MapCephalonMailgunInvitationDeliveryStatusCallbacks() at POST /engine/tenant-invitations/delivery-status/mailgun by default, fail-closed with optional ASP.NET Core policy configuration and endpoint-description opt-out
• translate bounded Mailgun webhook JSON object payloads, plus bounded JSON arrays for controlled replay/tests, into TenantInvitationDeliveryStatusReconciliationRequest using Cephalon user-variables, Mailgun event ids, message.headers.message-id, severity, delivery-status details, timestamp, and safe metadata
• publish diagnostics 4568, MailgunInvitationDeliveryStatusCallbackResult, MailgunInvitationDeliveryStatusCallbackEventResult, component docs, operations guidance, compatibility truth, maturity-audit ownership, package-surface coverage, and reference-doc alignment

Follow-up later:

• Mailgun HMAC signature verification later shipped through ENG-301; replay-token rejection later shipped through ENG-302; event-id idempotency later shipped through ENG-303; durable/distributed callback inboxes, distributed replay/event-id ledgers, provider polling, exactly-once delivery, additional provider-specific callback translators, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-301 Multi-tenancy invitation delivery Mailgun signed webhook verification baseline

Status: done Estimate: 5 Issue: #816

Why:

• after ENG-300, Cephalon could translate Mailgun callbacks into the existing delivery-status reconciler, but hosts still had to verify Mailgun’s signed webhook envelope before trusting callback content
• the smallest honest security proof is optional HMAC-SHA256 verification over timestamp + token with the Mailgun webhook signing key, not replay-token caching, durable callback inboxes, distributed event-id ledgers, provider polling, or exactly-once delivery

Delivered:

• add RequireSignedWebhook, WebhookSigningKey, SignedWebhookSignatureToleranceSeconds, and AcceptParentSignature to MailgunInvitationDeliveryAspNetCoreOptions
• verify Mailgun signed JSON envelopes before translation or reconciliation, including signature.signature plus optional signature.parent-signature support for subaccount events
• fail closed for missing signing keys, missing signature fields, malformed timestamps, stale timestamps, and invalid HMAC signatures without mutating invitation state or observations
• record only safe verification metadata such as outcome, ownership, algorithm, timestamp, age, signature field, parent-signature posture, and signature fingerprint
• publish callback-result signature posture, diagnostics 4569, runtime-surface signature ownership metadata, component docs, operations guidance, compatibility truth, maturity-audit ownership, package-surface coverage, and reference-doc alignment

Follow-up later:

• durable/distributed callback inboxes, distributed replay/event-id ledgers, provider polling, exactly-once delivery, additional provider-specific callback translators, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/ identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-302 Multi-tenancy invitation delivery Mailgun signed webhook replay protection baseline

Status: done Estimate: 5 Issue: #817

Why:

• after ENG-301, Cephalon could authenticate Mailgun signed webhook envelopes, but a verified token could still be replayed inside the accepted timestamp window unless the host added its own cache
• Mailgun recommends caching signed webhook tokens to prevent replay, and the smallest honest proof is bounded process-local token rejection, not a durable callback inbox or distributed replay ledger

Delivered:

• add EnableSignedWebhookReplayProtection, SignedWebhookReplayRetentionSeconds, and SignedWebhookReplayCacheLimit to MailgunInvitationDeliveryAspNetCoreOptions
• register a bounded process-local replay guard that stores SHA-256 token fingerprints only
• reject duplicate verified Mailgun signed webhook tokens with 409 before reconciliation
• record safe replay metadata such as outcome, policy, key type, scope, durability, retention, cache limit, and token fingerprint without storing raw tokens
• publish callback-result replay posture, diagnostics 4570, runtime-surface replay ownership metadata, component docs, operations guidance, compatibility truth, maturity-audit ownership, focused hosting coverage, and reference-doc alignment

Follow-up later:

• durable/distributed callback inboxes, distributed replay/event-id ledgers, provider polling, exactly-once delivery, additional provider-specific callback translators, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-303 Multi-tenancy invitation delivery Mailgun event-id idempotency baseline

Status: done Estimate: 5 Issue: #818

Why:

• after ENG-302, Cephalon could authenticate Mailgun callbacks and reject duplicate signed tokens, but provider retries with a fresh signed token could still carry the same Mailgun event id into the reconciler
• the narrow owned proof is observation-store-backed event-id duplicate suppression over mailgun:{event-data.id}, not a durable raw callback inbox, distributed event ledger, provider poller, or exactly-once delivery claim

Delivered:

• add EnableWebhookEventIdIdempotency to MailgunInvitationDeliveryAspNetCoreOptions
• check normalized mailgun:{event-data.id} observation ids in ITenantInvitationDeliveryStatusObservationStore before invoking the reconciler
• add DuplicateEvents, per-event duplicate-skipped results, safe reconciliation metadata, and runtime metadata for event-id idempotency outcome, ownership, policy, key, scope, store kind, and durability without storing raw payloads, raw signatures, raw tokens, or recipient email addresses
• project event-id idempotency posture through tenant-invitation-delivery-mailgun-status-callbacks and add diagnostic 4571 for duplicate event-id skips
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, and focused hosting coverage

Follow-up later:

• durable/distributed callback inboxes, distributed replay protection, distributed event-id ledgers, cross-node exactly-once claims, provider polling, additional provider-specific callback translators, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-304 Multi-tenancy invitation delivery Microsoft Graph sender baseline

Status: done Estimate: 5 Issue: #819

Why:

• after ENG-303, Cephalon could dispatch invitations through generic HTTP, SMTP, SendGrid, and Mailgun senders, but Microsoft 365 tenants still needed a first-party Graph sendMail handoff without writing host glue around the governance dispatcher
• the narrow owned proof is accepted-handoff email sending through Microsoft Graph with safe metadata, replaceable HTTP client and access-token provider seams, and explicit Microsoft Graph provider boundaries; it is not token-provider implementation before ENG-305, Graph notification processing, provider polling, delivery completion, or a durable callback inbox

Delivered:

• add Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery with AddCephalonMicrosoftGraphInvitationDelivery(...), MicrosoftGraphInvitationDeliveryOptions, IMicrosoftGraphInvitationDeliveryClient, IMicrosoftGraphInvitationDeliveryAccessTokenProvider, MicrosoftGraphInvitationDeliveryMessage, and MicrosoftGraphInvitationDeliveryClientResult
• register the default microsoft-graph-email ITenantInvitationDeliverySender, resolve recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, and prepare templated Graph JSON payloads for /v1.0/users/{SenderUserId}/sendMail or /v1.0/me/sendMail
• carry deterministic Cephalon message ids through safe custom x-* internet message headers and request metadata while recording only safe Graph status/request-id/header/category/recipient metadata and never recording bearer tokens, authorization headers, raw payloads, or message bodies
• accept Graph’s default 202 Accepted handoff, keep provider message id empty unless a custom client returns a truthful id, and emit diagnostics 4572-4573
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, and focused composition/tooling coverage

Follow-up later:

• Microsoft Entra app registration, permission consent, mailbox access policy, Graph change notifications, delivery completion after accepted sendMail handoff, provider polling, durable callback inboxes, distributed replay/event-id ledgers, Amazon SES v2 handoff later shipped through ENG-306; additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-305 Multi-tenancy invitation delivery Microsoft Graph Azure Identity token provider baseline

Status: done Estimate: 5 Issue: #820

Why:

• after ENG-304, the Microsoft Graph sender had a truthful access-token provider seam, but production hosts still needed to write boilerplate token-provider glue before using managed identity or workload identity
• the narrow owned proof is Azure Identity token acquisition for Graph scopes through an additive companion package; it is not Microsoft Entra application registration, permission consent, mailbox access policy, delivery completion after Graph accepts sendMail, Graph notification processing, provider polling, or a durable callback inbox

Delivered:

• add Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery.AzureIdentity with AddCephalonMicrosoftGraphInvitationDeliveryAzureIdentity(...) and MicrosoftGraphInvitationDeliveryAzureIdentityOptions
• register a replaceable IMicrosoftGraphInvitationDeliveryAccessTokenProvider backed by Azure Identity, with configuration/code-first DefaultAzureCredential setup, explicit TokenCredential injection, Graph scope selection, tenant id, managed-identity client id, authority-host selection, and safe interactive-browser/managed-identity credential toggles
• keep Graph sendMail ownership in Cephalon.MultiTenancy.Governance.MicrosoftGraphDelivery, while the Azure Identity companion only supplies bearer tokens and emits diagnostics 4574-4575 without recording token values, authorization headers, raw payloads, or message bodies
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, package-surface coverage, and focused composition/tooling coverage

Follow-up later:

• Microsoft Entra app registration, Graph Mail.Send permission consent, mailbox access policy, credential lifecycle policy beyond the host’s selected Azure credential, Graph change notifications, delivery completion after accepted sendMail handoff, provider polling, durable callback inboxes, distributed replay/event-id ledgers, Amazon SES v2 handoff later shipped through ENG-306; additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-306 Multi-tenancy invitation delivery Amazon SES sender baseline

Status: done Estimate: 5 Issue: #821

Why:

• after ENG-305, Cephalon could dispatch invitations through generic HTTP, SMTP, SendGrid, Mailgun, and Microsoft Graph senders, but AWS-hosted tenants still needed a first-party Amazon SES v2 handoff without writing host glue around the governance dispatcher
• the narrow owned proof is accepted-handoff email sending through Amazon SES v2 with safe metadata, a replaceable AWS SDK client seam, and explicit AWS provider boundaries; it is not AWS account/IAM setup, verified identities, DKIM/SPF/DMARC, sandbox exit, SES event publishing, provider polling, or a durable callback inbox, and Amazon SES over SNS callback translation is covered separately by ENG-307

Delivered:

• add Cephalon.MultiTenancy.Governance.AmazonSesDelivery with AddCephalonAmazonSesInvitationDelivery(...), AmazonSesInvitationDeliveryOptions, IAmazonSesInvitationDeliveryClient, AmazonSesInvitationDeliveryMessage, and AmazonSesInvitationDeliveryClientResult
• register the default amazon-ses-email ITenantInvitationDeliverySender, resolve recipient email from dispatch metadata, invitation metadata, or InviteeKind = email, and prepare templated SES v2 SendEmail requests with optional configuration sets, reply-to addresses, and normalized SES message tags
• record only safe region/configuration-set/status/message-id/tag/recipient metadata and never record AWS credentials, raw SDK payloads, raw request bodies, or message bodies
• accept SES’s successful 200 OK handoff with a SES MessageId, emit diagnostics 4576-4577, and keep the AWS SDK handoff replaceable for tests, gateways, or host-specific client policy
• update component docs, operations guidance, compatibility, maturity-audit ownership, planning truth, generated reference docs, and focused composition/tooling coverage

Follow-up later:

• AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox exit, configuration-set event destinations, Amazon SES over SNS callback translation now covered by ENG-307, provider polling, durable callback inboxes, distributed replay/event-id ledgers, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, cross-node retry leases, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-307 Multi-tenancy invitation delivery Amazon SES SNS callback translation baseline

Status: done Estimate: 5 Issue: #822

Why:

• after ENG-306, the SES sender could capture accepted handoff truth, but operators still needed a first-party way to translate SES event publishing callbacks without writing host glue around the governance reconciler
• the narrow owned proof is SNS-wrapped Amazon SES event payload translation into the existing delivery-status reconciler; it is not SNS signature verification, verified subscription confirmation, SES event-destination setup, provider polling, durable inboxing, distributed replay, or exactly-once delivery

Delivered:

• add Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore with AddCephalonAmazonSesInvitationDeliveryAspNetCore(...), AmazonSesInvitationDeliveryAspNetCoreOptions, MapCephalonAmazonSesInvitationDeliveryStatusCallbacks(), AmazonSesInvitationDeliveryStatusCallbackResult, and AmazonSesInvitationDeliveryStatusCallbackEventResult
• parse bounded SNS Notification envelopes, unwrap SES event publishing JSON from Message, extract Cephalon context tags from mail.tags, correlate mail.messageId to the SES sender provider message id, and translate SES delivery events through ITenantInvitationDeliveryStatusReconciler
• map Send, Delivery, Bounce, Complaint, Reject, Rendering Failure, and DeliveryDelay into normalized delivery statuses while skipping SNS confirmation/unsubscribe messages and engagement events by default
• project tenant-invitation-delivery-amazon-ses-status-callbacks, emit diagnostics 4578, keep SNS signature verification ownership separate for ENG-308, and keep subscription-confirmation, inbox, polling, distributed replay, and event-id ledger ownership explicit
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused composition/tooling coverage

Follow-up later:

• SNS signature verification now ships separately through ENG-308; process-local SNS replay protection now ships separately through ENG-309; observation-store-backed SNS message-id idempotency now ships separately through ENG-310; verified SNS subscription confirmation now ships separately through ENG-311; verified SNS unsubscribe-confirmation observation now ships separately through ENG-312; SES configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-308 Multi-tenancy invitation delivery Amazon SES SNS signature verification baseline

Status: done Estimate: 5 Issue: #823

Why:

• after ENG-307, Amazon SES over SNS callbacks could translate delivery events, but the endpoint still lacked a managed SNS signature-verification path
• AWS recommends verifying SNS signatures before processing HTTP(S) notifications or confirmation messages and rejecting unexpected TopicArn values
• the narrow owned proof is opt-in SNS envelope verification before translation; it is not verified subscription confirmation, SES event-destination setup, provider polling, durable inboxing, distributed replay, or exactly-once delivery

Delivered:

• add opt-in SNS signature verification to Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore through RequireSnsSignatureVerification, AllowedSnsTopicArns, signature-version policy, optional pinned PEM certificates, and certificate-chain validation posture
• verify SNS Notification, SubscriptionConfirmation, and UnsubscribeConfirmation envelopes before translation using the AWS SNS canonical string-to-sign, RSA signature validation, HTTPS Amazon SNS signing-certificate URL validation, and TopicArn allow-listing by default
• reject unverified callbacks before mapping or reconciliation, emit diagnostics 4579, record safe signature metadata, and project signature-version/topic/certificate policy through tenant-invitation-delivery-amazon-ses-status-callbacks
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused composition/tooling coverage

Follow-up later:

• process-local SNS replay protection now ships separately through ENG-309; observation-store-backed SNS message-id idempotency now ships separately through ENG-310; verified SNS subscription confirmation now ships separately through ENG-311; verified SNS unsubscribe-confirmation observation now ships separately through ENG-312; SES configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-309 Multi-tenancy invitation delivery Amazon SES SNS replay protection baseline

Status: done Estimate: 5 Issue: #824

Why:

• after ENG-308, Amazon SES over SNS callbacks could require SNS signature verification before translation, but a verified SNS message could still be replayed inside the same process window
• Amazon SNS Notification envelopes carry stable TopicArn and MessageId values, which gives Cephalon a bounded process-local replay key without claiming distributed exactly-once delivery
• the narrow owned proof is process-local replay rejection for verified SNS callbacks before reconciliation; it is not verified subscription confirmation, SES event-destination setup, provider polling, durable inboxing, distributed replay, or exactly-once delivery

Delivered:

• add EnableSnsReplayProtection, SnsReplayRetentionSeconds, and SnsReplayCacheLimit to Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore
• record bounded process-local replay fingerprints derived from verified SNS TopicArn plus MessageId and reject duplicate verified callbacks with 409 Conflict before reconciliation
• record safe replay metadata, emit diagnostics 4580, and project replay policy/key/scope/durability/retention/cache posture through tenant-invitation-delivery-amazon-ses-status-callbacks
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused composition/tooling coverage

Follow-up later:

• observation-store-backed SNS message-id idempotency now ships separately through ENG-310; verified SNS subscription confirmation now ships separately through ENG-311; verified SNS unsubscribe-confirmation observation now ships separately through ENG-312; SES configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-310 Multi-tenancy invitation delivery Amazon SES SNS message-id idempotency baseline

Status: done Estimate: 5 Issue: #825

Why:

• after ENG-309, verified Amazon SES over SNS callbacks could reject duplicate messages inside a bounded process-local replay window, but provider retry deliveries with a fresh process or disabled replay guard could still reach the reconciler repeatedly
• Amazon SNS Notification envelopes carry a stable MessageId, and the existing delivery-status observation store already records normalized observation ids, giving Cephalon a narrow duplicate-skip proof without claiming a distributed callback inbox or exactly-once delivery

Delivered:

• add EnableSnsMessageIdIdempotency to Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore
• check the normalized amazon-ses-sns:{MessageId} observation id in ITenantInvitationDeliveryStatusObservationStore before invoking the reconciler
• skip duplicate translated SNS events with per-event duplicate-skipped outcomes and aggregate duplicateEvents while preserving first-observation reconciliation semantics
• record safe message-id idempotency metadata, emit diagnostics 4581, and project message-id idempotency policy/key/scope/store-durability posture through tenant-invitation-delivery-amazon-ses-status-callbacks
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused composition/tooling coverage

Follow-up later:

• verified SNS unsubscribe-confirmation observation now ships separately through ENG-312; SNS topic/subscription creation, SES configuration-set event destination setup, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-311 Multi-tenancy invitation delivery Amazon SES SNS subscription confirmation baseline

Status: done Estimate: 5 Issue: #826

Why:

• after ENG-310, the Amazon SES over SNS callback adapter could verify SNS signatures, reject process-local replays, and skip duplicate notification MessageId observations, but hosts still had to manually confirm SNS HTTP subscriptions outside the engine
• SNS SubscriptionConfirmation envelopes use the same signed Amazon SNS envelope model, so Cephalon can own a narrow opt-in confirmation lane without claiming topic/subscription creation, SES event-destination setup, durable inboxing, or subscription lifecycle governance

Delivered:

• add EnableSnsSubscriptionConfirmation and SnsSubscriptionConfirmationTimeoutSeconds to Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore
• confirm only verified SNS SubscriptionConfirmation envelopes from allowed topics after SNS signature verification succeeds
• add replaceable IAmazonSesSnsSubscriptionConfirmationClient plus default bounded no-redirect HTTPS Amazon SNS SubscribeURL confirmation client
• return subscription-confirmation aggregate fields on AmazonSesInvitationDeliveryStatusCallbackResult, emit diagnostics 4582-4583, and project subscription-confirmation ownership/policy/timeout posture through tenant-invitation-delivery-amazon-ses-status-callbacks
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused composition/tooling coverage

Follow-up later:

• verified SNS unsubscribe-confirmation observation now ships separately through ENG-312; SNS topic/subscription creation, SES configuration-set event destination setup, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-312 Multi-tenancy invitation delivery Amazon SES SNS unsubscribe confirmation observation baseline

Status: done Estimate: 5 Issue: #827

Why:

• after ENG-311, the Amazon SES over SNS callback adapter could safely confirm signed SNS subscriptions when a host opted in, but verified UnsubscribeConfirmation envelopes still had no explicit runtime posture
• AWS SNS UnsubscribeConfirmation envelopes carry a SubscribeURL that can re-confirm or restore the subscription, so the honest Cephalon-owned proof is observe-only lifecycle posture, not automatic resubscribe or subscription lifecycle governance

Delivered:

• add EnableSnsUnsubscribeConfirmationObservation to Cephalon.MultiTenancy.Governance.AmazonSesDelivery.AspNetCore
• observe only verified SNS UnsubscribeConfirmation envelopes from allowed topics when SNS signature verification is required and successful
• require lifecycle fields, validate the trusted HTTPS Amazon SNS SubscribeURL, and never invoke it because visiting that URL can restore the subscription
• reuse bounded process-local replay posture, return unsubscribe-confirmation aggregate fields on AmazonSesInvitationDeliveryStatusCallbackResult, emit diagnostic 4584, and project unsubscribe-confirmation ownership/action/SubscribeURL policy through tenant-invitation-delivery-amazon-ses-status-callbacks
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused composition/tooling coverage

Follow-up later:

• SNS topic/subscription creation, SES configuration-set event destination setup, automatic resubscribe/restore, subscription lifecycle governance, provider polling, durable callback inboxes, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, and distributed/provider-backed governance stores remain future governance slices until a package truly owns those paths

ENG-313 Multi-tenancy delivery status observation rollup operator summary

Status: done Estimate: 3 Issue: #828

Why:

• after ENG-288, ASP.NET Core hosts could read bounded normalized delivery-status observation records, but operators still had to scan records manually to understand status, outcome, source, channel, sender, or tenant concentration
• the smallest honest follow-through is a filtered summary projection over the existing observation store, not a provider-specific callback inbox, provider polling loop, distributed replay ledger, or exactly-once delivery claim

Delivered:

• add TenantInvitationDeliveryStatusObservationSummaryDescriptor with dimension, value, count, reconciled count, recorded count, and latest observed/recorded timestamps
• extend TenantInvitationDeliveryStatusObservationQueryResult with SummaryCount and Summaries
• make GET /engine/tenant-invitations/delivery-status/observations return status, outcome, source, channel, sender, and tenant rollups from the matched normalized observation set before the response record limit is applied
• project observation-summary ownership, scope, and dimensions through tenant-invitation-delivery-status-http-endpoints
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused hosting/tooling coverage

Follow-up later:

• provider-specific callback inboxes, provider polling, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, distributed/provider-backed governance stores, and provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators remain future governance slices until a package truly owns those paths

ENG-314 Multi-tenancy delivery status observation attention drill-down baseline

Status: done Estimate: 3 Issue: #829

Why:

• after ENG-313, operators could see aggregate observation rollups, but they still had to know which statuses/outcomes counted as attention-worthy before drilling into records
• the smallest honest follow-through is an attention classifier and filter over the existing normalized observation store, not a provider-specific callback inbox, provider polling loop, distributed replay ledger, or exactly-once delivery claim

Delivered:

• add TenantInvitationDeliveryStatusObservationAttentionCategories with stable delivery-failed, delivery-deferred, delivery-suppressed, delivery-unknown, reconciliation-gap, and recording-gap labels
• make GET /engine/tenant-invitations/delivery-status/observations include an attention summary dimension derived from the matched normalized observation set before the response record limit is applied
• add the attention= query filter so operators can drill into attention-worthy observations without scanning all returned records
• project observation-attention ownership, scope, and supported categories through tenant-invitation-delivery-status-http-endpoints
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused hosting/tooling coverage

Follow-up later:

• provider-specific callback inboxes, provider polling, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, distributed/provider-backed governance stores, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, and provider-specific attention semantics beyond normalized observation categories remain future governance slices until a package truly owns those paths

ENG-315 Multi-tenancy delivery status observation remediation hints baseline

Status: done Estimate: 3 Issue: #830

Why:

• after ENG-314, operators could drill into attention-worthy normalized delivery-status observations, but they still had to infer the safest next action from status/outcome details on their own
• the smallest honest follow-through is deterministic remediation guidance derived from the matched normalized observation set, not provider polling, distributed callback inboxes, distributed remediation execution, or exactly-once delivery

Delivered:

• add TenantInvitationDeliveryStatusObservationRemediationActions with stable review-recipient-or-sender, monitor-deferred-delivery, review-suppression-policy, review-status-translation, review-reconciliation-input, and review-observation-recording labels
• add TenantInvitationDeliveryStatusObservationRemediationHintDescriptor plus RemediationHintCount and RemediationHints on TenantInvitationDeliveryStatusObservationQueryResult
• make GET /engine/tenant-invitations/delivery-status/observations return remediation hints derived from matched normalized observations before the response record limit is applied, including count, latest timestamps, and attention= drill-down filters
• project observation-remediation ownership, scope, and supported actions through tenant-invitation-delivery-status-http-endpoints
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused hosting/tooling coverage

Follow-up later:

• provider-specific callback inboxes, provider polling, distributed remediation execution, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, distributed/provider-backed governance stores, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, and provider-specific remediation semantics beyond normalized observation categories remain future governance slices until a package truly owns those paths

ENG-316 Multi-tenancy delivery status observation remediation action filter baseline

Status: done Estimate: 3 Issue: #831

Why:

• after ENG-315, operators could see deterministic remediation hints, but they still had to drill down by attention category instead of the stable next-action label they intended to review
• the smallest honest follow-through is an action filter and action summary over the matched normalized observation set, not provider polling, distributed callback inboxes, distributed remediation execution, or exactly-once delivery

Delivered:

• add a normalized remediation= query filter to GET /engine/tenant-invitations/delivery-status/observations
• add the remediation summary dimension derived from matched normalized observations before the response record limit is applied
• keep remediation hints derived from the same matched observation set, so action filters, summary buckets, and hints stay consistent
• project observation-remediation filter ownership and scope through tenant-invitation-delivery-status-http-endpoints
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused hosting/tooling coverage

Follow-up later:

• provider-specific callback inboxes, provider polling, distributed remediation execution, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, distributed/provider-backed governance stores, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, and provider-specific remediation semantics beyond normalized observation categories remain future governance slices until a package truly owns those paths

ENG-317 Multi-tenancy delivery status observation provider-message drill-down baseline

Status: done Estimate: 3 Issue: #832

Why:

• after ENG-316, operators could drill into attention and remediation posture, but provider callback investigations still needed a direct route from provider message ids back to normalized observation records
• the smallest honest follow-through is a provider-message filter and summary over the matched normalized observation set, not a provider-specific callback inbox, provider polling loop, distributed replay ledger, or exactly-once delivery claim

Delivered:

• add a providerMessageId= query filter to GET /engine/tenant-invitations/delivery-status/observations
• add the providerMessageId summary dimension derived from matched normalized observations before the response record limit is applied
• project observation provider-message filter ownership and scope through tenant-invitation-delivery-status-http-endpoints
• update component docs, operations guidance, compatibility, maturity-audit ownership, roadmap/backlog/project-memory truth, generated reference docs, GitHub tracking, and focused hosting/tooling coverage

Follow-up later:

• provider-specific callback inboxes, provider polling, distributed remediation execution, distributed replay/event-id ledgers, cross-node exactly-once delivery, public onboarding, tenant-admin UI, identity-provider synchronization, distributed retry queues, distributed/provider-backed governance stores, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, and provider-specific provider-message semantics beyond normalized observation fields remain future governance slices until a package truly owns those paths

Completed foundation work

ENG-000 App model and blueprint contract

Status: done Estimate: 5

Delivered:

• blueprint/app-model contracts
• pattern and transport selection
• technology-profile selection for future-facing workloads
• scaffold plans attached to the app profile
• configuration-driven blueprint selection

Follow-up later:

• expand the built-in technology catalog only when a workload needs distinct validation, guidance, or scaffold conventions
• avoid turning every new technology trend into a new blueprint unless it changes project shape materially

ENG-001 Module discovery from assemblies

Status: done Estimate: 8

Delivered:

• assembly-based module discovery
• opt-in discovery filters
• duplicate module-id and module-type validation
• deterministic ordering after discovery

ENG-002 Lifecycle hooks baseline

Status: done Estimate: 5

Delivered:

• initialize/start/stop lifecycle hooks
• dependency-ordered execution and reverse-order shutdown
• runtime status tracking
• lifecycle test coverage

ENG-003 Engine options and policy baseline

Status: done Estimate: 3

Delivered:

• EngineOptions
• module and capability toggles
• configuration-driven policy inputs
• runtime options introspection

Follow-up later:

• failure/restart policy
• richer startup policy and feature gating

ENG-004 Manifest v2

Status: done Estimate: 5

Delivered:

• manifest schema version
• engine version
• module version, metadata, dependencies, and tags
• capability source-module mapping

Follow-up later:

• compatibility strategy for future manifest revisions

ENG-006 Worker adapter baseline

Status: done Estimate: 5

Delivered:

• generic-host worker adapter
• worker playground
• shared lifecycle behavior between HTTP and worker hosts

ENG-007 ASP.NET Core contribution model baseline

Status: done Estimate: 8

Delivered:

• host mapping conventions for engine endpoints
• protocol-separated transport contribution model
• OpenAPI + Scalar for REST surfaces
• adapter split for companion transport packages such as JsonRpc and Grpc

ENG-008 Observability baseline

Status: done Estimate: 5

Delivered:

• engine logs, metrics, and tracing conventions
• startup summaries
• tests around diagnostics behavior

Follow-up later:

• richer export-ready telemetry
• production operations guidance

ENG-009 Blueprint-aware scaffolding and CLI baseline

Status: done Estimate: 8

Delivered:

• blueprint-aware scaffold plans
• concrete scaffold generation
• CLI generation workflow
• package-catalog alignment for generated test infrastructure dependencies

ENG-014 Protocol adapter packages baseline

Status: done Estimate: 8

Delivered:

• transport catalog
• host-aware transport gating
• runnable RestApi, JsonRpc, Grpc, ServerSentEvents, and WebSocket paths
• gRPC unary and streaming coverage

ENG-015 Benchmark suite baseline

Status: done Estimate: 5

Delivered:

• BenchmarkDotNet project in the solution
• composition benchmarks
• runtime lifecycle benchmarks
• scaffolding benchmarks

ENG-025 Technology companion packages baseline

Status: done Estimate: 13

Delivered:

• Cephalon.Agentics companion package for AgenticWorkloads
• Cephalon.Eventing companion package for EventDrivenIntegration
• Cephalon.Retrieval companion package for KnowledgeRetrieval
• Cephalon.Edge companion package for EdgeNativeDelivery
• ITechnologyServiceContributor and ITechnologyCapabilityContributor activation pattern
• scaffold/package hints aligned with built-in technology profiles
• playground and test coverage for technology-aware runtime services and capabilities

Follow-up later:

• add additional packs such as eventing, edge, or orchestration only when they need shared runtime primitives
• define publishing/versioning guidance for technology packs outside the repository

SDK hardening follow-through

Phase 1 SDK hardening, phase 2 operational hardening, phase 3 extensibility/package loading, and phase 4 execution/orchestration are now substantially complete on their shipped baselines. Phase 5 solution-level platform work is now also substantially complete on its shipped baseline, with the suite-scaffold contract baseline under #79, built-in MicroserviceSuite composition baseline under #80, multi-service suite sample baseline under #81, and shared governance plus additive gateway/control-plane guidance baseline under #82, while phase 6 keeps the shipped self-hosted OTLP slice, Azure Monitor first-vendor slice, AWS second-vendor slice, GCP third-vendor slice, Huawei Cloud fourth-vendor slice, Alibaba Cloud fifth-vendor slice, Red Hat OpenShift platform-first slice, DigitalOcean collector/defaults slice under #114, VMware Tanzu proxy/defaults slice under #118, downstream Cloudflare/custom-provider authoring guidance slice under #120, platform-neutral Kubernetes collector/defaults slice under #124, Grafana Cloud OTLP/header slice under #126, and New Relic native OTLP/api-key slice under #127, with any additional provider packs staying adoption-driven follow-through work.

ENG-005 Engine API and package surface hardening

Status: done Estimate: 4

Delivered:

• public-surface audit across abstractions, engine, adapters, scaffolding, tooling, and companion packages
• regression tests locking the intended exported surface for the CLI, reference-doc tooling, host adapters, worker adapter, scaffolding package, and companion packs
• package-facing guidance tightened so compatibility expectations are explicit across package manifests, scaffold output, template starters, and CLI flows
• the public surface now behaves like a supported product contract instead of repo-internal plumbing

ENG-026 GraphQL transport adapter

Status: done Estimate: 5

Delivered:

• dedicated Cephalon.AspNetCore.GraphQL adapter package built on Hot Chocolate
• GraphQL transport selection aligned across runtime introspection, scaffolding, and host registration
• working /graphql endpoint with module-driven schema contributions on ASP.NET Core
• integration coverage and component docs for GraphQL hosting guidance

ENG-027 DocFX XML-comment readiness beyond shipped packages

Status: done Estimate: 8

Delivered:

• XML comments added across benchmark, sample, and reference-module public APIs that belong in the supported published docs set
• supported DocFX/reference-doc boundary documented explicitly for shipped packages, samples, benchmarks, and reference modules
• tests/Cephalon.Tests excluded from generated docs scope so test-only fixtures do not blur supported documentation input

ENG-028 Repo-wide XML-comment hygiene for test harnesses

Status: done Estimate: 6

Delivered:

• tests/Cephalon.Tests now keeps shared test-harness types internal where safe while leaving only framework-required xUnit classes and a small reflective transport-contract exception public
• tooling coverage now locks that policy by asserting the test assembly exports only xUnit test classes plus the explicit allow-listed transport contract exception and that XML-document generation stays disabled for the test project
• reference-doc and compatibility guidance now state the test-harness policy explicitly so the supported DocFX/reference-doc boundary stays limited to shipped packages and intentionally promoted samples

ENG-030 Release package artifact baseline

Status: done Estimate: 8

Why:

• the repo now validates build, test, benchmarks, and reference docs, but it still lacks an explicit release-pack baseline for the NuGet and template artifacts we actually intend to ship
• dotnet pack currently drifts across benchmarks, playgrounds, sample-only libraries, and CLI/tooling surfaces without a repo-owned definition of the intended package boundary

Delivered:

• the intended release packable surface is now explicit: shipped src/Cephalon.* packages plus the reference module and template pack, with benchmarks, playgrounds, sample-only libraries, and the unfinished CLI install surface excluded by default
• shared NuGet metadata and a repo-owned package readme baseline now flow through Directory.Build.props so shipped packages publish with consistent authorship, repository, license, and readme metadata
• scripts/publish-package-artifacts.ps1 now publishes deterministic release artifacts under artifacts/packages-release and emits a manifest of the packaged project set
• scripts/validate-release.ps1, the release-validation workflow, docs, and tooling coverage now all validate the same package-artifact baseline instead of leaving packaging drift implicit

ENG-031 CLI tool packaging baseline

Status: done Estimate: 8

Why:

• ENG-030 made the intended release artifact set explicit, but it also left Cephalon.Cli out on purpose until the repository ships a truthful dedicated install surface instead of a generic library-style nupkg
• the docs currently center dotnet run --project src/Cephalon.Cli -- ..., which is fine for repo contributors but not yet the external adoption path we want to validate and publish as a supported CLI install story

Delivered:

• Cephalon.Cli now ships as an explicit .NET tool package with the stable cephalon command name and a package-specific readme instead of staying outside the release package boundary
• the release package-artifact flow now includes the CLI tool package alongside the shipped library and template artifacts
• tooling coverage now validates the packed tool metadata, package contents, and a local install/execute smoke path from the produced Cephalon.Cli artifact
• package-publishing docs, compatibility guidance, and repository usage examples now document the supported CLI install path explicitly instead of centering dotnet run --project as the only adoption story

ENG-032 Release package provenance manifest baseline

Status: done Estimate: 5

Delivered:

• the published release package-artifact manifest now carries top-level SourceRepository and SourceRevision fields so downstream automation can tie package sets back to the repository revision that produced them
• each packed project now publishes PackageKind plus per-file Path, FileName, SizeBytes, and Sha256 metadata instead of leaving checksum verification to ad-hoc file inspection
• the release flow now emits package-artifacts.sha256 alongside package-artifacts-manifest.json so operators can verify package files without parsing JSON
• package-publishing guidance, compatibility notes, and tooling coverage were updated so the shipped release-artifact contract stays explicit and truthful

Current operational focus

Phase 2 operational hardening is now substantially complete:

• keep the completed gap inventory, shipped OpenTelemetry companion package, shipped Serilog companion package, and published diagnostics catalog reflected accurately in docs and project tracking
• keep the shipped Cassandra, ClickHouse, Consul, Elasticsearch, HTTP, Kafka, Memcached, MongoDB, MQTT, MySQL, NATS, Neo4j, OpenSearch, Oracle, Postgres, RabbitMQ, Redis, and SQL Server dependency-health companion baseline reflected accurately in docs and project tracking, with any additional provider packs treated as future adoption-driven expansion work
• keep the shipped ASP.NET Core request/response logging, bounded body capture, trace/log correlation, runtime-story, and failure-policy warmup/drain/restart-backoff surfaces reflected accurately in docs and project tracking
• keep the shipped operational release-validation guidance for health and telemetry-export conventions reflected accurately in docs and project tracking
• keep self-hosted plus cloud-vendor tracing/export follow-through tracked under ENG-029 instead of leaving it as an implied phase-2 blocker
• keep docs/operational-hardening-gap-inventory.md current as the source of truth for what phase-2 gaps were closed versus what moved into later phases

ENG-016 Blueprint sample suite

Status: done Estimate: 8

Delivered:

• samples/ now exists alongside playground/
• sample projects for ModularMonolith, ModularVerticalSlice, and Microservice
• the sample suite is wired into the main solution
• smoke hosting tests verify each sample boots and exposes its expected app model and endpoint shape

ENG-017 dotnet new / template-pack support

Status: done Estimate: 8

Delivered:

• Cephalon.TemplatePack project in the main solution
• installable dotnet new entries for ModularMonolith, ModularVerticalSlice, and Microservice
• package metadata and readme for the template pack
• pack validation and dotnet new smoke coverage in tests
• documentation for local pack/install/create flow

Follow-up later:

• richer template parameterization
• tighter convergence between template content and Cephalon.Scaffolding
• upgrade/version guidance once the package distribution story is formalized

ENG-018 Module SDK and authoring path

Status: done Estimate: 8

Delivered:

• cephalon-module and cephalon-rest-module starters in Cephalon.TemplatePack
• cephalon-rest-behavior-module starter in Cephalon.TemplatePack
• a reference module package at samples/Cephalon.ReferenceModule.Operations
• integration coverage for discovery, lifecycle, capability registration, localization, and REST contribution
• docs/module-authoring.md for the recommended package workflow

Follow-up later:

• richer module-template parameterization
• additional transport-specific authoring starters beyond REST
• packaging/version guidance for publishing reference modules externally

Near-term hardening work

ENG-019 Runtime failure and restart policy

Status: done Estimate: 13

Delivered:

• Engine:FailurePolicy configuration with startup and stop behaviors
• runtime failure context in RuntimeStatusSnapshot
• runtime restart guards and explicit RestartAsync(...)
• host introspection through /engine/failure-policy and /engine/status
• test coverage for fail-fast startup, capture-only startup, best-effort stop, and host startup behavior

Follow-up later:

• richer retry/backoff policies
• failure-event integration with observability/export pipelines
• more operator-facing automation over restart workflows

ENG-020 Operational health and telemetry exports

Status: done Estimate: 13

Delivered:

• /health, /health/live, and /health/ready with runtime-backed JSON responses
• RuntimeHealthEvaluator shared across ASP.NET Core, worker hosts, and observability
• IDependencyHealthContributor baseline for host-agnostic dependency health reporting
• /engine/dependencies for dependency-level runtime introspection
• /engine/diagnostics with meter, activity source, counter names, and live health reports
• runtime failure and restart counters for telemetry baselines
• Engine:Observability:Telemetry config contract plus startup log guidance
• Engine:Observability:HttpLogging plus opt-in ASP.NET Core request/response logging with bounded body capture and request/trace correlation
• default sensitive-value redaction across query-string, JSON, form, and header-style plain-text HTTP logging payloads

Follow-up later:

• adoption-driven provider-specific dependency health packs beyond the shipped Cassandra, ClickHouse, Consul, Elasticsearch, HTTP, Kafka, Memcached, MongoDB, MQTT, MySQL, NATS, Neo4j, OpenSearch, Oracle, Postgres, RabbitMQ, Redis, and SQL Server baseline

ENG-021 Benchmark guardrails in validation flow

Status: done Estimate: 5

Delivered:

• repository guardrail catalog for the shipped benchmark scenarios
• CSV reader and validator in Cephalon.Benchmarks
• CLI validation command for the latest BenchmarkDotNet reports
• test coverage for benchmark report parsing and guardrail evaluation
• benchmark docs updated with the validation flow
• composition and runtime benchmarks now prepare configured builders, runtimes, and service providers outside the measured loop so guardrails track Build() and lifecycle transition costs directly
• composition baseline thresholds refreshed to match the prepared-scenario hot path shipped in the release-validation flow
• ASP.NET Core request logging now has a shipped guardrail scenario that covers correlated request/response body capture over the public host surface
• the benchmark catalog now also covers strict trust-policy composition plus bounded-truncation and concurrent ASP.NET Core request-logging paths

Follow-up later:

• expand guardrails as new hot paths become important
• revisit baseline thresholds when benchmark scenarios evolve materially

ENG-024 Explicit package assembly loading baseline

Status: done Estimate: 13

Delivered:

• Engine:Discovery:Packages configuration contract for explicit module assembly paths
• EngineBuilder.AddPackageAssembly(...) and package-reference builder support
• assembly-path package loading with a dedicated load context and explicit failure diagnostics
• package-manifest loading through Engine:Discovery:Packages:ManifestPath and EngineBuilder.AddPackageManifest(...)
• package-directory discovery through Engine:Discovery:PackageDirectories and EngineBuilder.AddPackageDirectory(...)
• package compatibility and integrity metadata through cephalon.package.json
• Engine:PackagePolicy baseline for requiring manifest-driven package loads and stricter package metadata
• publisher and signer provenance metadata plus trust allow-lists for package governance
• detached-signature verification against trusted public keys and trusted signing certificate chains
• manifest/runtime introspection through package metadata and /engine/packages
• integration coverage using Cephalon.ReferenceModule.Operations as a real package-loaded module

Follow-up later:

• external distribution hooks and broader provenance attestations beyond the current signature-verification baseline
• versioned package distribution guidance outside the repository

ENG-023 GitHub Actions release-validation baseline

Status: done Estimate: 5

Delivered:

• .github/workflows/release-validation.yml for push, pull_request, and manual runs
• GitHub Actions execution on windows-latest using the SDK pinned in global.json
• CI wired to the repo-native scripts/validate-release.ps1 flow instead of duplicating build/test/benchmark logic in YAML
• benchmark result artifact upload for CI inspection

Follow-up later:

• split faster PR validation from deeper release/publish workflows if the repo needs it
• add package-publishing and release-version automation when distribution is formalized

Platform expansion work

ENG-011 Package and plugin loading

Status: done Estimate: 5

Why:

• Cephalon becomes a platform when modules are distributable independently

Delivered:

• package discovery inputs through Engine:Discovery:Packages, Engine:Discovery:PackageDirectories, and the package builder APIs
• explicit package load failures for missing manifests, duplicate registrations, integrity mismatches, and dependency-registration gaps
• manifest-declared compatibility, target-framework, version, and package-dependency validation through cephalon.package.json
• package policy, detached-signature verification through trusted public keys or trusted signing certificate chains, publisher/signer provenance, and trust hooks surfaced through Engine:PackagePolicy, Engine:Trust, and /engine/packages
• external package distribution metadata and provenance metadata surfaced through distribution, provenance, and /engine/packages
• authoring guidance for externally distributed packages, including release-channel, package URI, source revision, build URI, and provenance statement hints

ENG-012 Capability permissions and trust policy

Status: done Estimate: 8

Delivered:

• Engine:Trust configuration contract with package trust, assembly trust, and per-capability access rules
• capability decisions surfaced through CapabilityPolicyEvaluator and /engine/trust-policy
• package manifests and module manifests now carry trust status
• REST request-time enforcement through RequireCapability(...)
• test coverage for trusted package loading, denied capabilities, and HTTP boundary enforcement

Follow-up later:

• richer scopes beyond per-capability allow, trusted-only, and deny
• trust hooks beyond explicit assembly-path packages
• policy and trust integration for future non-REST runtime boundaries

ENG-013 Workflow and orchestration primitives

Status: done Estimate: 5

Why:

• this is the bridge from framework to execution platform

Delivered:

• a first execution-graph contract through IExecutionGraphContributor, ExecutionGraphDescriptor, and IExecutionRuntimeCatalog
• a first hosted/background execution contract through IHostedExecutionContributor, HostedExecutionDescriptor, and IHostedExecutionRuntimeCatalog
• additive runtime introspection through /engine/execution-graphs and /engine/snapshot
• additive hosted/background introspection through /engine/hosted-executions and /engine/snapshot
• build-time validation for graph ids, nodes, edges, referenced modules, and referenced capability keys
• build-time validation for hosted-execution ids, source modules, and referenced execution graphs
• execution-graph lifecycle state through /engine/runtime-story and /engine/snapshot, including operator-visible load, activate, and deactivate transitions
• hosted/background execution lifecycle state through /engine/runtime-story and /engine/snapshot, including operator-visible load, activate, and deactivate transitions
• runtime diagnostics coverage for execution-graph and hosted/background lifecycle transitions through cephalon.execution-graphs.transitions, cephalon.hosted-executions.transitions, and the Cephalon.Engine event-id catalog
• agentic tool descriptors can now link back to capability keys, execution graphs, and hosted executions through the existing Cephalon.Agentics contract
• /engine/technology-surfaces and /engine/snapshot now project those linked AI/orchestration surfaces with live runtime-story state
• invalid agent-tool references to unknown capability keys, execution graphs, or hosted executions now fail when the agentic tool catalog is resolved
• module-author guidance for publishing workflow and execution-graph descriptors without bypassing the existing module/capability model
• descriptive hosted/background execution conventions that stay on top of the existing module and Generic Host model instead of introducing a separate engine-owned runner abstraction

ENG-022 MicroserviceSuite blueprint

Status: done Estimate: 2

Why:

• the current shipped blueprints focus on individual apps or services, not coordinated suites

Delivered:

• public suite-scaffold contracts through SuiteScaffoldPlan, SuiteScaffoldService, and ScaffoldScopes.Suite
• explicit separation between shared suite projects/folders and per-service slots so future multi-service blueprints do not overload the current single-app ScaffoldPlan
• validation that suite services can only depend on declared shared projects or other declared service slots
• a built-in MicroserviceSuite blueprint through SuiteBlueprint and BuiltInSuiteBlueprints
• suite shared-foundation and repeatable service-slot defaults composed from the shipped Microservice scaffold contract instead of redefining host, contracts, and module project shapes a second time
• a reference Cephalon.Sample.MicroserviceSuite sample with a shared foundation project plus separate catalog and orders microservice hosts
• smoke coverage proving both suite services boot, stay on the shipped Microservice blueprint, and surface shared suite conventions through their runtime endpoints
• a shared Cephalon.Sample.MicroserviceSuite.Governance package that keeps suite-level governance guidance outside the engine core and outside any one service host
• additive gateway and control-plane guidance that stays sample-level and consumes the existing /engine/* runtime surfaces instead of inventing a new engine-owned coordinator

Current cloud and platform integration work

ENG-029 Cloud-targeted observability companion integrations

Status: done Estimate: 268

Why:

• the self-hosted OTLP collector/runtime-default slice plus the Azure Monitor, AWS, GCP, Huawei Cloud, Alibaba Cloud, Oracle Cloud, Red Hat OpenShift, DigitalOcean, VMware Tanzu, and platform-neutral Kubernetes slices are now shipped, #120 has now shipped downstream Cloudflare and custom-provider authoring guidance instead of a misleading first-party Cloudflare exporter package, and #126 has now shipped the Grafana Cloud first-party follow-through target instead of reopening the remaining provider matrix as one vague task
• current New Relic native OTLP docs exposed region-specific OTLP endpoints, the required api-key header, and an OTLP/HTTP recommendation that fit a provider-specific companion package without moving vendor assumptions back into the engine core, and that explicit follow-through is now shipped under #127
• current Cloudflare Workers observability docs center Worker-native traces and logs plus exporting OpenTelemetry-compliant traces and logs from Workers to third-party OTLP destinations, with metrics export still unsupported, so a generic Cephalon host-side Cloudflare sink would over-claim the current platform story
• this work should stay in companion packages, preserve the shared ILogger pipeline plus the cloud-neutral OTLP baseline, and leave room for downstream developer-authored provider packages

Acceptance:

• keep the shipped self-hosted deployment defaults explicit and reusable instead of burying them inside vendor-specific companion packs
• keep the shipped Azure Monitor, AWS, GCP, Huawei Cloud, Alibaba Cloud, Oracle Cloud, Red Hat OpenShift, DigitalOcean, and Kubernetes slices explicit on top of the shared OpenTelemetry baseline
• keep the shipped Red Hat OpenShift and DigitalOcean companion follow-through explicit instead of rolling them back into one ambiguous remaining-platform scope
• keep the shipped DigitalOcean collector-first follow-through explicit instead of over-claiming a managed DigitalOcean OTLP exporter surface that the current platform docs do not promise
• keep the shipped Kubernetes collector-first follow-through explicit on top of the shared OTLP baseline instead of folding generic cluster defaults back into OpenShift, DigitalOcean, or downstream custom-provider guidance
• keep the shipped Oracle Cloud managed traces/metrics follow-through explicit on top of the shared OTLP baseline instead of folding Oracle Cloud APM-specific data-upload and data-key rules back into Huawei Cloud, Alibaba Cloud, or downstream custom-provider guidance
• keep the shipped VMware Tanzu proxy-first follow-through explicit on top of the shared OTLP baseline instead of reopening Cloudflare or pretending the current Tanzu docs describe one generic vendor-direct OTLP exporter path
• keep the shipped #120 scope centered on downstream Cloudflare and custom-provider companion authoring guidance until Cloudflare documents a host-side ingestion story that fits Cephalon’s .NET runtime model
• keep the shipped #126 scope centered on Grafana Cloud OTLP endpoint wiring plus access-policy-backed auth headers on top of the shared OTLP baseline instead of reopening a generic remaining-provider task
• keep the shipped #127 scope centered on New Relic native OTLP endpoint wiring plus api-key-backed headers and region-aware defaults on top of the shared OTLP baseline instead of reopening a generic remaining-provider task
• keep vendor/platform-specific exporter wiring, auth, resource attributes, and hosted defaults outside Cephalon.Engine and Cephalon.Abstractions
• keep the shared ILogger pipeline and existing Cephalon.Observability.OpenTelemetry baseline intact
• add docs, validation, and planning sync for the supported targets plus the downstream companion-package authoring path, including shipped Grafana Cloud OTLP/header guidance, shipped New Relic OTLP/api-key guidance, and Cloudflare-oriented guidance that stays honest about the current Worker-native export model
• avoid shipping a first-party Cephalon.Observability.Cloudflare package unless Cloudflare later exposes a documented generic OTLP ingestion story for external hosts
• keep any provider beyond the shipped New Relic slice as a later explicit child item instead of reopening the remaining provider matrix as one task

Next adoption and operator readiness work

ENG-033 Cross-platform validation and shell parity baseline

Status: done Estimate: 13 Completed: April 4, 2026

Completed work:

• updated scripts/validate-release.ps1 plus the package-publishing, reference-doc publishing, and operational-validation helper scripts so nested PowerShell invocations run through the active host with pwsh-friendly parameter binding instead of Windows-only assumptions
• updated .github/workflows/release-validation.yml to run the same repo-native validation flow on both Windows and Ubuntu without duplicating build/test/publish logic in workflow YAML
• extended tooling coverage around package publishing, reference-doc publishing, and release validation so the supported shell path stays locked to the same repo-native scripts
• aligned release-validation, package-publishing, and adoption docs with the supported Windows, WSL, and Linux-class shell path

Why:

• the current repo-native validation and publishing flow still invokes Windows PowerShell directly and GitHub Actions currently proves it only on windows-latest, even though Cephalon’s host/runtime model is meant to stay host-agnostic
• local install smoke coverage for the CLI tool and template pack already exists, but the shipped automation still does not prove those same paths on Linux-class shells or WSL-friendly environments
• hardening the shell and CI path now is higher leverage than adding more engine surface because it stabilizes every shipped package, sample, and tool

Acceptance:

• repo-native PowerShell scripts use a cross-platform invocation strategy that works under PowerShell 7 / pwsh
• release validation runs on both Windows and Linux without duplicating build/test/publish logic in workflow YAML
• CLI tool install/help and template install/generate smoke coverage prove a Linux-compatible path in addition to the current Windows path
• docs call out the supported local validation path for Windows, WSL, and Linux-class shells

ENG-034 First-run adoption and environment doctor path

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• the repo now has a strong quick start plus package/template/tool install coverage, but new adopters still do not have one first-class answer for “is my environment set up correctly?”
• Cephalon.Cli currently focuses on generation and docs publishing, which leaves install, upgrade, and runtime-smoke validation spread across multiple docs and package readmes
• a first-run doctor path will reduce support friction and make the framework easier to adopt outside the repo

Acceptance:

• Cephalon.Cli ships a first-class doctor or equivalent environment-verification command that checks the expected SDK/tool/template/runtime prerequisites
• docs add a dedicated getting-started/adoption guide that walks from install to generated-app run and /engine/* inspection
• CLI help text, README guidance, and package readmes stay aligned with the same first-run path
• automated coverage proves the doctor/verification flow and its documented happy path

Completed work:

• shipped cephalon doctor in Cephalon.Cli with required SDK/runtime checks plus advisory template-pack detection
• added docs/getting-started.md as the install, verification, scaffold, run, and /engine/* inspection path
• aligned CLI help text, README.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the doctor-first adoption flow
• added CLI and documentation coverage for the doctor happy path, required-failure path, and doc/readme alignment

ENG-035 External module package lifecycle prove-out

Status: done Estimate: 13 Completed: April 4, 2026

Why:

• the engine can already load manifest-driven packages with trust and provenance metadata, but the repo still proves most of that story through repo-local references and docs rather than an operator-facing end-to-end workflow
• a practical framework needs a repeatable “author package, publish artifact, trust it, load it, inspect it” baseline outside the repo-local assembly path
• this work keeps package loading explicit and introspectable while making the external distribution story concrete enough for real adopters

Acceptance:

• the reference module or an equivalent sample package can be published as an external artifact and loaded into a host from an out-of-tree package location
• docs show the full package author -> publish -> trust -> load -> inspect flow using cephalon.package.json, Engine:PackagePolicy, and Engine:Trust
• automated coverage proves external package load paths, trust/policy outcomes, and runtime introspection outside the repo-local assembly-only scenario
• package-publishing guidance stays aligned with the prove-out flow

Completed work:

• shipped cephalon package stage in Cephalon.Cli so published module .nupkg artifacts can be materialized into loadable package directories outside the repo-local assembly path
• added end-to-end CLI and ASP.NET Core host coverage that packs Cephalon.ReferenceModule.Operations, stages it into an out-of-tree package directory, loads it through Engine:Discovery:PackageDirectories, and verifies trust/policy/runtime-introspection surfaces
• added docs/external-package-lifecycle.md as the operator-facing publish -> stage -> trust -> load -> inspect walkthrough
• aligned docs/package-publishing.md, docs/module-authoring.md, samples/Cephalon.ReferenceModule.Operations/README.md, CLI docs, and package readme guidance with the same external package staging flow

ENG-036 Containerized local runtime and operations baseline

Status: done Estimate: 13 Completed: April 4, 2026

Completed work:

• made Cephalon.Sample.ModularMonolith container-friendly by letting late command-line or environment configuration override the sample JSON baseline and by wiring Cephalon.Observability.OpenTelemetry
• added a Dockerfile, compose.yaml, collector config, optional package-directory compose override, sample README, and plugin placeholder so the modular monolith sample can run under Docker Desktop / WSL with the same /engine/* and /health/* surfaces
• added docs/container-runtime.md, aligned the root/docs/operations guidance with the same container path, and shipped the optional scripts/validate-container-runtime.ps1 smoke entry point without making Docker a release-validation dependency
• added hosting and tooling coverage for the container assets/configuration path and verified the sample through the shipped Docker compose smoke flow

Why:

• the repo ships runnable samples and strong /engine/* introspection surfaces, but it still lacks a reproducible Docker Desktop / WSL-friendly path for validating a host with production-like deployment boundaries
• operators and adopters need a concrete local deployment shape for health checks, telemetry configuration, package mounts, and environment-driven settings before Cephalon feels practical beyond source builds
• this work can prove the existing engine/runtime surface through sample-level assets without pushing Docker-specific behavior into Cephalon.Engine

Acceptance:

• at least one adoption-quality sample host ships with a Dockerfile and container run guidance that preserve current config-loading and /engine/* surfaces
• a Docker Compose or equivalent local orchestration path proves app startup, health endpoints, and at least one telemetry/export handoff or collector path
• docs explain how to run the sample under Docker Desktop / WSL and where to inspect runtime, health, and package surfaces
• validation guidance includes a containerized smoke path without making Docker a required engine dependency

ENG-037 Generated app local package-feed bootstrap baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps from cephalon new and the shipped dotnet new starters can expose the right runtime shape, but a fresh adopter still needs a truthful first-run answer for where Cephalon packages come from before restore, build, or container startup will work outside this repo
• the shared package version baseline had drifted far enough that dotnet pack could default repo artifacts to 1.0.0 while scaffolds, templates, and docs still expected the preview package line, which makes adoption guidance look correct while restore/install behavior disagrees
• phase 7 should close the gap between “I can scaffold an app” and “I can actually build and run that generated app” without requiring repo-only NuGet knowledge

Acceptance:

• generated apps from both cephalon new and the app-focused dotnet new starters emit NuGet.config plus a documented local package-feed placeholder by default
• shared package-version defaults stay aligned with the preview package line used by scaffolds, templates, docs, and the CLI tool install path
• docs explain how to seed the generated-app local feed or replace the cephalon package source before first build and first container run
• automated coverage plus a real smoke flow prove scaffold -> package publish -> restore/build -> Docker compose startup and the expected /engine/*, /health/*, and docs surfaces

Completed work:

• aligned shared Cephalon.* package-version defaults in Directory.Build.props back to 0.1.0-preview so packed artifacts, templates, scaffolds, and install docs point at the same prerelease baseline
• updated Cephalon.Scaffolding and the shipped app templates to emit NuGet.config, .cephalon/packages/README.md, and README guidance that explain the seeded-local-feed bootstrap path
• removed the redundant ASP.NET Core framework reference from generated web hosts so the generated app build stays warning-free on the supported path
• aligned README.md, docs/getting-started.md, docs/container-runtime.md, docs/package-publishing.md, docs/components/scaffolding.md, CLI package guidance, and template-pack guidance with the prerelease install plus local-feed bootstrap flow
• added scaffolding, CLI, template-pack, package-publishing, and documentation coverage for the generated-app bootstrap contract, then verified a real generated app through scaffold -> publish-package-artifacts into ./.cephalon/packages -> dotnet build -> docker compose up --build with /engine/snapshot, /health/ready, and /scalar

ENG-038 Generated app published-output and deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages and take the documented container path, but adopters still need a truthful deployment-like answer for publishing and starting a Cephalon host from emitted artifacts instead of a source-tree build
• without a shipped publish profile and a smoke path that exercises published output, teams still have to rediscover host project paths, output conventions, and runtime probes before they can trust the generated app beyond local source builds
• phase 7 should close the gap between “I can build and container-run a generated app” and “I can publish and run the generated output” without repo-only MSBuild or host-startup knowledge

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit a deterministic folder publish profile by default
• docs explain how to publish and run a generated app from published output, including the supported seeded or repointed cephalon package-source expectation
• automated coverage plus an optional validation script prove scaffold -> package publish -> folder publish -> run published output and the expected /engine/*, /health/*, and docs surfaces
• published-output guidance stays aligned across scaffolding, CLI, template-pack, and operations docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit Properties/PublishProfiles/CephalonFolder.pubxml that publish into deterministic artifacts/publish/<ProjectName>/ output without forcing an app host executable
• added docs/generated-app-publishing.md and aligned README.md, docs/getting-started.md, docs/container-runtime.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the published-output path
• added scripts/validate-generated-app-publish.ps1 so the repo can scaffold a temporary app, seed local packages, publish the host, start the published DLL, and validate /health/ready, /engine, /engine/snapshot, and /scalar
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated publish contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> dotnet publish -p:PublishProfile=CephalonFolder -> run published output

ENG-039 Generated app Linux systemd deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take the documented container path, but adopters still need a truthful self-hosted Linux answer for turning that published output into a long-running service on a VM or bare-metal host
• without shipped service assets and a verification path, teams still have to rediscover /opt/* layout, environment-file location, and systemctl install steps before they can trust the generated app outside local shells or container tooling
• phase 7 should close the gap between “I can publish the app” and “I can package the published output into a Linux service-manager shape” without pushing Linux-service behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit Linux systemd deployment assets by default
• docs explain how to install published output plus the generated unit/environment files on a Linux target and how to validate the unit before enabling it
• automated coverage plus an optional validation script prove scaffold -> package publish -> folder publish -> Linux systemd unit verification under WSL or Linux-class shells
• Linux self-hosted guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, and generated-app publishing docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/linux/systemd/README.md, deploy/linux/systemd/<App>.service, and deploy/linux/systemd/<App>.env alongside the existing publish/container assets
• added docs/linux-systemd-deployment.md and aligned README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/container-runtime.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the Linux self-hosted path
• added scripts/validate-generated-app-systemd.ps1 so the repo can scaffold a temporary app, seed local packages, publish the host, rewrite the generated unit to WSL-visible publish paths, and run systemd-analyze verify
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated Linux deployment contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> dotnet publish -p:PublishProfile=CephalonFolder -> WSL systemd-analyze verify

ENG-040 Generated app Windows Service deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take both the documented container path and Linux self-hosted path, but Windows-first teams still need a truthful self-hosted answer for turning that published output into a long-running service without rediscovering sc.exe arguments and content-root handling
• without shipped install assets plus Windows Service-aware host wiring, teams still have to rediscover C:\Services\* layout, --contentRoot handling, and service-recovery commands before they can trust the generated app outside local shells or container tooling
• phase 7 should close the gap between “I can publish the app” and “I can package the published output into a Windows service-manager shape” without pushing Windows-only behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit Windows Service deployment assets by default
• generated hosts are wired for Windows Service lifetime and content-root handling without changing the blueprint or engine contracts
• docs explain how to preview, install, verify, and remove the generated Windows Service assets on a Windows target
• automated coverage plus an optional validation script prove scaffold -> package publish -> folder publish -> Windows Service install preview against published output
• Windows self-hosted guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, and generated-app publishing docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/windows-service/README.md, deploy/windows-service/install-service.ps1, and deploy/windows-service/remove-service.ps1 alongside the existing publish/container/Linux assets
• updated generated ASP.NET Core host wiring plus the shipped app templates to use Microsoft.Extensions.Hosting.WindowsServices, WindowsServiceHelpers.IsWindowsService(), and builder.Host.UseWindowsService() so service lifetime and content-root behavior stay aligned under SCM startup
• added docs/windows-service-deployment.md and aligned README.md, docs/README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the Windows self-hosted path
• added scripts/validate-generated-app-windows-service.ps1 so the repo can scaffold a temporary app, seed local packages, publish the host, verify the generated Windows Service host wiring, and replay the shipped install/remove scripts in preview mode against published output
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated Windows deployment contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> dotnet publish -p:PublishProfile=CephalonFolder -> Windows Service install preview

ENG-041 Generated app IIS deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take both the documented self-hosted Windows and Linux paths, but Windows-hosted teams still need a truthful IIS answer for turning that published output into a site plus app-pool deployment without rediscovering the ASP.NET Core Module contract
• without shipped IIS assets plus guidance around the SDK-generated web.config, teams still have to rediscover C:\inetpub\sites\* layout, appcmd.exe flow, hosting-bundle prerequisites, and ANCM expectations before they can trust the generated app on a hosted Windows baseline
• phase 7 should close the gap between “I can publish the app” and “I can package the published output into an IIS site/app-pool shape” without pushing IIS-specific behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit IIS deployment assets by default
• generated published output keeps the expected ASP.NET Core Module web.config so IIS can launch the host through dotnet
• docs explain how to preview, install, verify, and remove the generated IIS assets on a Windows target
• automated coverage plus an optional validation script prove scaffold -> package publish -> folder publish -> IIS install preview against published output
• IIS hosted guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, and generated-app publishing docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/iis/README.md, deploy/iis/install-site.ps1, and deploy/iis/remove-site.ps1 alongside the existing publish, container, Windows Service, and Linux assets
• aligned generated app and template README guidance with the hosted Windows IIS path built on top of the SDK-generated ASP.NET Core Module web.config
• added docs/iis-deployment.md and aligned README.md, docs/README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the IIS hosted path
• added scripts/validate-generated-app-iis.ps1 so the repo can scaffold a temporary app, seed local packages, publish the host, verify the generated web.config, and replay the shipped IIS install/remove scripts in preview mode against published output
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated IIS deployment contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> dotnet publish -p:PublishProfile=CephalonFolder -> IIS install preview

ENG-042 Generated app Azure App Service deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take self-hosted Windows/Linux plus hosted IIS paths, but cloud-hosted teams still need a truthful Azure App Service answer for turning that published output into a deployable ZIP artifact without rediscovering the run-from-package contract
• without shipped Azure App Service assets plus guidance around WEBSITE_RUN_FROM_PACKAGE=1, az webapp deploy, and the deterministic ZIP package path, teams still have to rediscover packaging and deploy-preview behavior before they can trust the generated app on a hosted Azure baseline
• phase 7 should close the gap between “I can publish the app” and “I can package the published output into an Azure App Service ZIP-deploy shape” without pushing Azure-specific behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit Azure App Service deployment assets by default
• generated deployment assets package published output into a deterministic ZIP artifact and preserve the expected SDK-generated web.config
• docs explain how to preview, package, and deploy the generated Azure assets with the current Azure CLI contract
• automated coverage plus an optional validation script prove scaffold -> package publish -> folder publish -> Azure App Service ZIP packaging and preview against published output
• Azure App Service guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, and generated-app publishing docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/azure-app-service/README.md and deploy/azure-app-service/deploy-zip.ps1 alongside the existing publish, container, Windows Service, IIS, and Linux assets
• aligned generated app and template README guidance with the hosted Azure App Service ZIP-deploy path built on top of the deterministic CephalonFolder.pubxml publish output
• added docs/azure-app-service-deployment.md and aligned README.md, docs/README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the Azure App Service path
• added scripts/validate-generated-app-app-service.ps1 so the repo can scaffold a temporary app, seed local packages, publish the host, package the generated ZIP artifact, and replay the shipped Azure deploy script in preview mode against the current Azure CLI contract
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated Azure App Service deployment contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> dotnet publish -p:PublishProfile=CephalonFolder -> Azure App Service ZIP packaging and deploy preview

ENG-043 Generated app Azure Container Apps deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take self-hosted Windows/Linux plus hosted IIS and Azure App Service paths, but cloud-hosted teams using Azure’s container-native platform still need a truthful Container Apps answer from the shipped Dockerfile and app root without inventing another deployment script from scratch
• without shipped Azure Container Apps assets plus guidance around az containerapp up --source, ingress, target port, and baseline environment variables, teams still have to rediscover source-root deployment behavior before they can trust the generated app on a hosted Azure container baseline
• phase 7 follow-through should close the gap between “I can validate the generated Dockerfile locally” and “I can deploy the generated app to Azure Container Apps” without pushing Azure-specific behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit Azure Container Apps deployment assets by default
• generated deployment assets validate the source root and preview the current Azure CLI contract from the shipped Dockerfile/app root shape
• docs explain how to preview and deploy the generated Azure Container Apps assets with az containerapp up --source
• automated coverage plus an optional validation script prove scaffold -> package publish -> local Docker build -> Azure Container Apps deploy preview against the generated app root
• Azure Container Apps guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, and generated-app publishing docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/azure-container-apps/README.md and deploy/azure-container-apps/deploy-up.ps1 alongside the existing publish, container, Windows Service, IIS, Azure App Service, and Linux assets
• aligned generated app and template README guidance with the hosted Azure Container Apps source-deploy path built on top of the shipped Dockerfile and NuGet.config bootstrap
• added docs/azure-container-apps-deployment.md and aligned README.md, docs/README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the Azure Container Apps path
• added scripts/validate-generated-app-container-apps.ps1 so the repo can scaffold a temporary app, seed local packages, validate the generated Dockerfile locally, and replay the shipped Azure deploy script in preview mode against the current Azure CLI contract
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated Azure Container Apps deployment contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> local Docker build -> Azure Container Apps deploy preview

ENG-044 Generated app Kubernetes deployment baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take self-hosted Windows/Linux plus hosted IIS, Azure App Service, and Azure Container Apps paths, but teams deploying onto generic or self-managed Kubernetes clusters still need a truthful manifest/apply answer from the shipped Dockerfile and app root without inventing a second deploy workflow
• without shipped Kubernetes assets plus guidance around kubectl kustomize, namespace shape, service exposure, and baseline health probes, teams still have to rediscover cluster-ready manifest conventions before they can trust the generated app on a platform-neutral Kubernetes baseline
• adoption follow-through should close the gap between “I can validate the generated Dockerfile locally” and “I can render/apply the generated app onto Kubernetes” without pushing cluster-specific behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit Kubernetes deployment assets by default
• generated deployment assets render the manifest set locally and preview the current kubectl kustomize contract from the shipped Dockerfile/app root shape
• docs explain how to preview and apply the generated Kubernetes assets, including namespace, service, and health-probe expectations
• automated coverage plus an optional validation script prove scaffold -> package publish -> local Docker build -> Kubernetes manifest preview against the generated app root
• Kubernetes guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, and generated-app publishing docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/kubernetes/README.md, deploy/kubernetes/apply.ps1, deploy/kubernetes/kustomization.yaml, deploy/kubernetes/namespace.yaml, deploy/kubernetes/deployment.yaml, and deploy/kubernetes/service.yaml alongside the existing publish, container, Windows Service, IIS, Azure App Service, Azure Container Apps, and Linux assets
• aligned generated app and template README guidance with the Kubernetes manifest/apply path built on top of the shipped Dockerfile and NuGet.config bootstrap
• added docs/kubernetes-deployment.md and aligned README.md, docs/README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the Kubernetes path
• added scripts/validate-generated-app-kubernetes.ps1 so the repo can scaffold a temporary app, seed local packages, validate the generated Dockerfile locally, and replay the shipped Kubernetes apply script in preview mode against the current kubectl kustomize contract
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated Kubernetes deployment contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> local Docker build -> Kubernetes manifest preview

ENG-045 Generated app container-image publishing baseline

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• generated apps can now bootstrap packages, publish deterministically, and take self-hosted Windows/Linux plus hosted IIS, Azure App Service, Azure Container Apps, and Kubernetes paths, but teams still need a truthful provider-neutral image build/tag/push answer from the shipped Dockerfile and app root without inventing a registry workflow from scratch
• without shipped container-image assets plus guidance around docker build, docker push, additional tags, and registry auth expectations, teams still have to rediscover how Cephalon’s generated Dockerfile should become a pullable image before they can trust the hosted container baselines
• adoption follow-through should close the gap between “I can validate the generated Dockerfile locally” and “I can publish a pullable image for Kubernetes or another hosted container platform” without pushing registry-specific behavior into Cephalon.Engine

Acceptance:

• generated hosts from both cephalon new and the shipped app-focused dotnet new starters emit container-image publishing assets by default
• generated publish assets preview the current docker build and docker push contract from the shipped Dockerfile/app root shape and can build one or more image tags without hidden repo assumptions
• docs explain how to preview, build, and push the generated container-image assets, including reuse with the hosted container deployment baselines
• automated coverage plus an optional validation script prove scaffold -> package publish -> local Docker build -> local-registry push against the generated app root
• container-image guidance stays aligned across scaffolding, CLI, template-pack, getting-started, operations, generated-app publishing, and the hosted container deployment docs

Completed work:

• updated Cephalon.Scaffolding and the shipped app templates to emit deploy/container-image/README.md and deploy/container-image/publish-image.ps1 alongside the existing publish, container, Windows Service, IIS, Azure App Service, Azure Container Apps, Kubernetes, and Linux assets
• aligned generated app and template README guidance with the provider-neutral container image build/tag/push path built on top of the shipped Dockerfile and NuGet.config bootstrap
• added docs/container-image-publishing.md and aligned README.md, docs/README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/operations.md, docs/components/scaffolding.md, docs/components/cli.md, CLI package guidance, and template-pack guidance with the container-image path
• added scripts/validate-generated-app-container-image.ps1 so the repo can scaffold a temporary app, seed local packages, preview the shipped build/push contract, build the generated image, and prove push through a local Docker registry backed by registry:2
• extended scaffolding, CLI, template-pack, and documentation coverage for the generated container-image publishing contract, then verified a real smoke path through scaffold -> publish-package-artifacts into ./.cephalon/packages -> generated publish-image.ps1 -> local registry push

ENG-210 Deployment-mode support contract baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-097 made the .NET 11 readiness lane truthful, but the trim / Native AOT / single-file support statement still lived only in prose across readiness, compatibility, and package-publishing docs
• without a machine-readable support contract, future project-property changes could drift ahead of the docs or the readiness report and accidentally over-claim deployment-mode support
• external adopters need one explicit contract that answers “what does Cephalon support today” before the repo widens its official deployment matrix

Acceptance:

• the repo ships a machine-readable deployment-mode support manifest that records the current trim, Native AOT, and single-file support statement
• scripts/validate-dotnet-readiness.ps1 reads that manifest, publishes it back into the readiness report, and fails if project-detected claim status drifts away from the manifest-backed support contract
• hand-authored support docs and package-publishing guidance stay aligned with the same manifest-backed support story
• focused tooling coverage proves the readiness report and docs alignment without widening current repo truth beyond not-claimed

ENG-211 Doctor support-contract follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-210 made the deployment-mode support contract machine-readable, but external adopters still had to read repo docs or readiness artifacts to see that truth
• cephalon doctor was already the first-run install and bootstrap command, so it was the sharpest place to surface the stable shipping floor, readiness lane, and advanced deployment-mode posture without inventing a second adoption path
• the packaged CLI should carry the same support-contract answer even when the tool is installed outside the source repository

Acceptance:

• Cephalon.Cli packages the existing deployment-mode support manifest as part of the tool so cephalon doctor can read one truth source without hardcoding a second contract in C#
• cephalon doctor echoes the stable net10.0 shipping floor plus the .NET 11 assessment-only readiness lane directly in command output
• cephalon doctor keeps trim, Native AOT, and single-file support visible as non-blocking not-claimed warnings while they remain outside the support contract
• the getting-started guide, CLI docs, CLI package README, template-pack README, and root README all stay aligned with the same doctor-driven support-contract story
• focused tooling coverage proves the doctor output and adoption docs stay aligned with the packaged support contract

Completed work:

• added scripts/deployment-mode-support.json as the machine-readable trim / Native AOT / single-file support contract, including the current net10.0 shipping floor and net11.0 readiness-lane metadata
• updated scripts/validate-dotnet-readiness.ps1 so readiness reports now project the support manifest, validate project-detected claim status against it, and fail if the manifest documentation paths drift
• added docs/deployment-mode-support.md and aligned docs/README.md, docs/dotnet11-readiness.md, docs/compatibility.md, and docs/package-publishing.md with the same support-contract story
• extended focused tooling coverage so readiness-report JSON plus Markdown output and the framework-readiness docs hub all stay aligned with the new manifest-backed contract

ENG-212 Generated app doctor support-contract follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-211 surfaced the packaged deployment-mode support contract at machine scope, but external adopters still had to infer whether a generated app stayed on the stable shipping floor or drifted into the .NET 11 readiness lane or an unclaimed publish mode
• cephalon doctor --app-root <path> was already the generated-app bootstrap validation command, so it was the sharpest place to compare a scaffolded host’s target framework and publish settings against the same packaged support contract
• generated-app verification should answer whether the app is still inside the current Cephalon support contract before restore, publish, or deployment work begins

Acceptance:

• cephalon doctor --app-root <path> reads the generated host target framework and compares it against the stable net10.0 shipping floor plus the .NET 11 assessment-only readiness lane
• generated-app doctor reads effective PublishTrimmed, PublishAot, and PublishSingleFile settings from the generated host project or publish profile and compares them against the packaged deployment-mode support contract
• stable-floor hosts emit [ok], readiness-lane or unclaimed deployment-mode settings emit [warn], and out-of-contract frameworks emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, deployment-mode-support guide, compatibility guide, .NET 11 readiness guide, CLI package README, and template-pack README stay aligned with the same generated-app support-contract story
• focused tooling coverage proves stable-floor, readiness-lane, unclaimed publish-mode, and out-of-contract generated-app answers on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now inspects TargetFramework or TargetFrameworks, compares them against the packaged support contract, and keeps stable-versus-readiness-versus-out-of-contract posture visible directly in doctor output
• added effective generated-app deployment-mode checks for PublishTrimmed, PublishAot, and PublishSingleFile by reading the generated host project together with CephalonFolder.pubxml
• aligned the adoption docs and package READMEs so generated-app doctor now explicitly documents target-framework and publish-claim validation alongside the earlier bootstrap checks
• extended focused tooling coverage so stable-floor generated apps stay green, readiness-lane plus unclaimed publish-mode apps warn truthfully, and out-of-contract generated hosts fail doctor with the expected error posture

ENG-214 Generated app doctor self-hosted and hosted deployment-asset alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-213 made generated-app doctor truthful about the shipped Dockerfile and container deployment assets, but external adopters could still drift the generated Windows Service, IIS, Azure App Service, or Linux systemd assets without the same command path warning them before they replayed published-output deployment flows
• cephalon doctor --app-root <path> was already the generated-app bootstrap, support-contract, and deployment-asset command, so it was the sharpest place to validate those self-hosted and hosted assets instead of inventing another published-output verification surface
• generated-app verification should answer whether the scaffolded published-output deployment shape still matches the current host identity before teams rely on Windows Service, IIS, Azure App Service, or Linux systemd replays

Acceptance:

• cephalon doctor --app-root <path> validates the shipped Windows Service, IIS, Azure App Service, and Linux systemd deployment assets alongside the earlier container deployment checks
• generated-app doctor compares those generated published-output deployment scripts and units against the current host identity so host-assembly or app-id drift becomes visible before deployment work begins
• aligned self-hosted and hosted deployment assets emit [ok], while missing or drifted published-output deployment assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, generated-app publishing guide, deployment-mode-support guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated published-output deployment-asset doctor story
• focused tooling coverage proves aligned published-output deployment assets, missing self-hosted and hosted deployment assets, and drifted published-output deployment scripts on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the shipped Windows Service, IIS, Azure App Service, and Linux systemd deployment assets as part of the generated-app bootstrap answer
• added generated published-output baseline checks that compare those Windows Service, IIS, Azure App Service, and Linux systemd assets against the current host identity before replaying deployment flows

ENG-215 Generated app doctor local orchestration asset alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-214 made generated-app doctor truthful about published-output deployment assets, but external adopters could still drift the generated compose.yaml or otel-collector-config.yaml assets without the same command path warning them before they replayed local docker compose up --build
• cephalon doctor --app-root <path> was already the generated-app bootstrap, support-contract, and deployment-asset command, so it was the sharpest place to validate those local orchestration assets instead of inventing another local container-runtime verification surface
• generated-app verification should answer whether the scaffolded local orchestration shape still matches the current Dockerfile plus OTLP collector baseline before teams rely on docker compose up --build

Acceptance:

• cephalon doctor --app-root <path> validates the shipped compose.yaml and otel-collector-config.yaml assets alongside the earlier container and published-output deployment checks
• generated-app doctor compares the generated compose file against the shipped Dockerfile, OTLP collector handoff, and current local container defaults
• generated-app doctor compares the generated collector config against health_check, otlp/http on 4318, and the debug-exporter pipeline shape
• aligned local orchestration assets emit [ok], while missing or drifted compose or collector assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, container-runtime guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated local orchestration doctor story
• focused tooling coverage proves aligned local orchestration assets, missing generated local orchestration assets, and drifted compose or collector baselines on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the shipped compose.yaml and otel-collector-config.yaml assets as part of the generated-app bootstrap answer
• added generated local orchestration baseline checks that compare compose.yaml against the shipped Dockerfile plus OTLP collector handoff and compare otel-collector-config.yaml against the expected health-check, otlp/http, and debug-exporter pipeline shape before replaying local docker compose up --build
• aligned README.md, docs/getting-started.md, docs/generated-app-publishing.md, docs/deployment-mode-support.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated self-hosted and hosted deployment-asset doctor flow
• extended focused CLI and documentation coverage for aligned published-output deployment assets, missing self-hosted and hosted deployment assets, and drifted published-output deployment scripts

ENG-216 Generated app doctor documentation-surface config alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-215 made generated-app doctor truthful about local orchestration assets, but external adopters could still drift Configurations/AddOpenApi.json or Configurations/AddReferenceDocs.json without the same command path warning them before they relied on /scalar or optional hosted reference docs
• cephalon doctor --app-root <path> was already the generated-app bootstrap, support-contract, and deployment-asset command, so it was the sharpest place to validate those documentation-surface config assets instead of inventing another docs-verification command
• generated-app verification should answer whether the scaffolded OpenAPI and hosted reference-doc config shape still stays explicit in split project settings before teams rely on those docs surfaces

Acceptance:

• cephalon doctor --app-root <path> validates the generated Configurations/AddOpenApi.json and Configurations/AddReferenceDocs.json assets alongside the earlier bootstrap, deployment-asset, and support-contract checks
• generated-app doctor verifies that the generated OpenAPI settings still keep an explicit OpenApi:Title
• generated-app doctor verifies that the generated hosted reference-doc settings still keep explicit ReferenceDocs:Enabled, RoutePrefix, DirectoryPath, and DefaultDocument values
• aligned documentation-surface assets emit [ok], while missing or drifted OpenAPI or hosted reference-doc config assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, reference-docs guide, CLI package README, and template-pack README stay aligned with the same generated documentation-surface doctor story
• focused tooling coverage proves aligned documentation-surface assets, missing generated documentation-surface assets, and drifted OpenAPI or hosted reference-doc baseline settings on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the shipped Configurations/AddOpenApi.json and Configurations/AddReferenceDocs.json assets as part of the generated-app bootstrap answer
• added generated documentation-surface baseline checks that compare AddOpenApi.json against an explicit OpenApi:Title and compare AddReferenceDocs.json against explicit hosted reference-doc enablement, route, directory, and default-document settings before teams rely on /scalar or hosted reference docs
• aligned README.md, docs/getting-started.md, docs/components/cli.md, docs/reference-docs.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated documentation-surface doctor flow
• extended focused CLI and documentation coverage for aligned documentation-surface assets, missing generated documentation-surface assets, and drifted OpenAPI or hosted reference-doc baseline settings

ENG-217 Generated app doctor split-config alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-216 made generated-app doctor truthful about documentation-surface config, but external adopters could still drift Configurations/AddEngine.*.json or Configurations/Observability/Development.json without the same command path warning them before they relied on generated runtime, docs, localization, or telemetry defaults
• cephalon doctor --app-root <path> was already the generated-app bootstrap, support-contract, and deployment-asset command, so it was the sharpest place to validate those split-config assets instead of inventing another configuration-verification command
• generated-app verification should answer whether the scaffolded split project configuration surface still keeps app-model, engine-feature, observability, localization, and development Serilog defaults explicit before teams rely on those generated baselines

Acceptance:

• cephalon doctor --app-root <path> validates the generated Configurations/AddEngine.*.json assets plus Configurations/Observability/Development.json alongside the earlier bootstrap, deployment-asset, and support-contract checks
• generated-app doctor verifies that the generated app-model split-config still keeps explicit Engine:Blueprint, Engine:Discovery:Assemblies, Engine:Patterns, Engine:Technologies, and Engine:Transports selections
• generated-app doctor verifies that the generated engine feature split-config still keeps explicit Engine:Data, Engine:Identity, Engine:Tenancy, Engine:Audit:Enabled, and Engine:Messaging sections
• generated-app doctor verifies that the generated observability, localization, and development Serilog baselines still keep explicit telemetry, culture, resource, and console-sink defaults
• aligned split-config assets emit [ok], while missing or drifted split-config assets or baseline sections emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated split-config doctor story
• focused tooling coverage proves aligned split-config assets, missing generated split-config assets, and drifted split-config baselines on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the shipped Configurations/AddEngine.*.json assets plus Configurations/Observability/Development.json as part of the generated-app bootstrap answer
• added generated split-config baseline checks that compare the app-model, engine-feature, observability, localization, and development Serilog settings against explicit scaffolded defaults before teams rely on those generated baselines
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated split-config doctor flow
• extended focused CLI and documentation coverage for aligned split-config assets, missing generated split-config assets, and drifted split-config baseline settings

ENG-218 Generated app doctor host-bootstrap alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-217 made generated-app doctor truthful about split project configuration, but external adopters could still drift the scaffolded Program.cs host bootstrap source or the generated host-project PackageReference plus Configurations/**/*.json copy/publish baseline without the same command path warning them before they relied on edited startup or build/publish behavior
• cephalon doctor --app-root <path> was already the generated-app bootstrap, support-contract, deployment-asset, and split-config command, so it was the sharpest place to validate those host-bootstrap seams instead of inventing another startup-verification command
• generated-app verification should answer whether the scaffolded host startup and host-project baseline still keep explicit AddCephalonProjectConfigurations, observability wiring, MapCephalon, and split-config copy/publish behavior visible before teams rely on edited startup code

Acceptance:

• cephalon doctor --app-root <path> validates the scaffolded Program.cs bootstrap source plus the generated host-project PackageReference set and Configurations/**/*.json copy/publish baseline alongside the earlier bootstrap, support-contract, deployment-asset, and split-config checks
• generated-app doctor verifies that the generated host bootstrap source still keeps explicit AddCephalonProjectConfigurations, builder.AddCephalon(...), observability wiring, builder.Logging.ClearProviders(), builder.AddCephalonSerilog(), builder.AddCephalonOpenTelemetry(), app.UseExceptionHandler(), and app.MapCephalon() flow
• generated-app doctor verifies that the generated host project still keeps the scaffolded PackageReference set plus CopyToOutputDirectory=PreserveNewest and CopyToPublishDirectory=PreserveNewest on Configurations/**/*.json
• aligned host bootstrap assets emit [ok], while missing or drifted bootstrap source or host-project baseline assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated host-bootstrap doctor story
• focused tooling coverage proves aligned host-bootstrap assets and drifted Program.cs or host-project baselines on the same doctor path

ENG-219 Generated app doctor test-harness alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• docs and package readmes already told external adopters that generated app starters ship Architecture/CompositionSmokeTests.cs plus per-feature Features/*BehaviorSpecifications.cs, but cephalon doctor --app-root <path> still had no truthful way to warn when those starter test-harness seams drifted
• the generated-app doctor path already owned bootstrap, support-contract, split-config, docs-surface, deployment-asset, and orchestration truth, so it was the sharpest place to keep the scaffolded starter tests explicit instead of inventing another starter-verification command
• generated-app verification should answer whether the starter composition smoke test plus Given/When/Then behavior placeholders are still present before teams replace them with real specs

Acceptance:

• cephalon doctor --app-root <path> validates that at least one generated test project exists under tests/
• generated-app doctor validates that the scaffolded Architecture/CompositionSmokeTests.cs keeps the generated composition smoke placeholder explicit
• generated-app doctor validates that at least one Features/*BehaviorSpecifications.cs file exists and keeps the generated Given/When/Then placeholder explicit
• aligned starter tests emit [ok], while missing or drifted generated test-harness assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated starter test-harness doctor story
• focused tooling coverage proves aligned starter tests and drifted composition smoke or behavior-specification placeholders on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates generated test-project discovery plus the scaffolded Architecture/CompositionSmokeTests.cs and Features/*BehaviorSpecifications.cs placeholders as part of the same generated-app bootstrap answer
• added generated test-harness baseline checks that compare the composition smoke test against the scaffolded placeholder method and compare feature-specification files against the starter Given/When/Then placeholder before teams replace those files with real specs
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated starter test-harness doctor flow
• extended focused CLI and documentation coverage for aligned starter tests and drifted composition smoke or behavior-specification placeholders on the same doctor path

ENG-220 Generated app doctor guidance-doc alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• generated app starters already ship human-facing README.md, Configurations/README.md, and deploy/*/README.md guidance, but cephalon doctor --app-root <path> still had no truthful way to warn when those scaffolded instructions drifted away from the current package-source, split-config, publish, or deployment contract
• phase-7 external adoption depends on those scaffolded docs as much as the scripts they reference, because external teams will often follow the generated guidance before they inspect the repo docs
• the generated-app doctor path already owned bootstrap, support-contract, split-config, docs-surface, deployment-asset, orchestration, and starter-test truth, so it was the sharpest place to keep the scaffolded human-facing guidance explicit instead of inventing a separate docs-verification command

Acceptance:

• cephalon doctor --app-root <path> validates the generated root README.md, src/<Host>/Configurations/README.md, and generated deployment README.md assets under deploy/
• generated-app doctor verifies that the root README still keeps explicit package-source, split-config, publish, deployment, and local-orchestration guidance for the current generated app id
• generated-app doctor verifies that the configuration README still keeps explicit Configurations/Add*.json, grouped override, and AddCephalonProjectConfigurations() guidance
• generated-app doctor verifies that the Windows Service, IIS, Azure App Service, container-image, Azure Container Apps, Kubernetes, and Linux systemd READMEs still keep explicit generated run/publish/deploy instructions aligned with the current app root
• aligned guidance docs emit [ok], while missing or drifted generated guidance docs emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated guidance-doc doctor story
• focused tooling coverage proves aligned generated guidance docs plus missing or drifted guidance-doc baselines on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the scaffolded root README.md, Configurations/README.md, and generated deployment README.md assets as part of the same generated-app bootstrap answer
• added generated guidance-doc baseline checks that compare root package-source/split-config/publish/deploy/orchestration guidance plus configuration and deployment guide seams against the scaffolded doctor contract before teams follow those docs literally
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated guidance-doc doctor flow
• extended focused CLI and documentation coverage for aligned generated guidance docs, missing guidance-doc assets, and drifted root guidance on the same doctor path

ENG-221 Generated app doctor local package-feed guidance alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• generated app starters already ship .cephalon/packages/README.md, but cephalon doctor --app-root <path> still had no truthful way to warn when the scaffolded local package-feed seeding and shared-feed replacement guidance drifted away from the current package-bootstrap contract
• phase-7 external adoption depends on that guide as much as NuGet.config, because external teams often seed repo-local packages or swap to a shared cephalon source before they inspect the broader repo docs
• the generated-app doctor path already owned bootstrap, support-contract, split-config, docs-surface, deployment-asset, orchestration, starter-test, and guidance-doc truth, so it was the sharpest place to keep the scaffolded local package-feed guidance explicit instead of inventing a separate package-bootstrap verification command

Acceptance:

• cephalon doctor --app-root <path> validates the generated .cephalon/packages/README.md asset alongside the earlier generated guidance docs
• generated-app doctor verifies that the local package-feed README still keeps explicit NuGet.config, publish-package-artifacts.ps1, shared-feed replacement, and Dockerfile/compose restore guidance
• aligned local package-feed guidance emits [ok], while missing or drifted local package-feed guidance emits [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, and template-pack README stay aligned with the same local package-feed doctor story
• focused tooling coverage proves aligned local package-feed guidance plus missing or drifted local package-feed guidance baselines on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the scaffolded .cephalon/packages/README.md asset as part of the same generated-app bootstrap answer
• added a generated local package-feed guidance baseline check that compares local package-feed seeding plus shared-feed replacement instructions against the scaffolded doctor contract before teams seed packages or swap NuGet.config
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated local package-feed guidance doctor flow
• extended focused CLI and documentation coverage for aligned local package-feed guidance plus missing or drifted local package-feed guidance on the same doctor path

ENG-224 Generated app doctor teardown-script and systemd environment alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-214 made generated-app doctor truthful about the shipped Windows Service, IIS, Azure App Service, and Linux systemd deployment assets, but external adopters could still drift the generated Windows Service removal script, IIS teardown script, or Linux systemd environment file without the same command path warning them before replaying those operational flows
• generated apps already ship deploy/windows-service/remove-service.ps1, deploy/iis/remove-site.ps1, and deploy/linux/systemd/<App>.env, so phase-7 external adoption still needed one truthful answer for whether those teardown and environment assets still matched the current generated app id and published-output baseline
• the generated-app doctor path already owned bootstrap, support-contract, docs-surface, split-config, deployment-asset, deployment-script, and Kubernetes manifest truth, so it was the sharpest place to keep teardown and service-manager environment posture explicit instead of inventing a separate operational validation surface

Acceptance:

• cephalon doctor --app-root <path> validates the generated deploy/windows-service/remove-service.ps1, deploy/iis/remove-site.ps1, and deploy/linux/systemd/<App>.env assets alongside the earlier published-output deployment checks
• generated-app doctor verifies that the Windows Service remove script still keeps explicit Get-Service, Stop-Service, and sc.exe delete seams for the current generated app id
• generated-app doctor verifies that the IIS remove script still keeps explicit stop site, delete site, and delete apppool seams for the current generated app id
• generated-app doctor verifies that the Linux systemd environment file still keeps explicit DOTNET_ENVIRONMENT, ASPNETCORE_URLS, and commented telemetry override hints for the shipped service-manager baseline
• aligned generated teardown and environment assets emit [ok], while drifted assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, generated-app publishing guide, Windows Service guide, IIS guide, and Linux systemd guide stay aligned with the same teardown and environment doctor story
• focused tooling coverage proves aligned teardown/environment assets plus drifted Windows Service remove-script, IIS remove-script, and Linux systemd environment baselines on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the scaffolded deploy/windows-service/remove-service.ps1, deploy/iis/remove-site.ps1, and deploy/linux/systemd/<App>.env assets as part of the same generated-app bootstrap answer
• added generated teardown and environment baseline checks that compare Windows Service stop/delete flow, IIS site/app-pool teardown flow, and Linux systemd environment plus telemetry override hints against the scaffolded doctor contract before teams replay those operational assets literally
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, docs/generated-app-publishing.md, docs/windows-service-deployment.md, docs/iis-deployment.md, and docs/linux-systemd-deployment.md with the generated teardown and environment doctor flow
• extended focused CLI and documentation coverage for aligned teardown/environment assets plus drifted Windows Service remove-script, IIS remove-script, and Linux systemd environment baselines on the same doctor path

ENG-222 Generated app doctor container deployment-script alignment baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-213 made generated-app doctor truthful about the shipped Dockerfile plus container deployment assets, but external adopters could still drift the executable container deployment scripts they actually run without the same command path warning them before image publish, Azure Container Apps, or Kubernetes work
• generated apps already ship deploy/container-image/publish-image.ps1, deploy/azure-container-apps/deploy-up.ps1, and deploy/kubernetes/apply.ps1, so phase-7 external adoption still needed one truthful answer for whether those scaffolded scripts still matched the current Dockerfile, NuGet.config, host-project/source-root, image placeholder, namespace, and manifest-root contract
• the generated-app doctor path already owned bootstrap, support-contract, split-config, docs-surface, deployment-asset, orchestration, starter-test, and guidance truth, so it was the sharpest place to keep executable container deployment-script posture explicit instead of inventing a separate container-script verification surface

Acceptance:

• cephalon doctor --app-root <path> validates the generated deploy/container-image/publish-image.ps1, deploy/azure-container-apps/deploy-up.ps1, and deploy/kubernetes/apply.ps1 assets alongside the earlier container deployment-asset checks
• generated-app doctor verifies that the container-image script still keeps explicit Dockerfile, NuGet.config, image placeholder, and preview/push flow seams for the current generated app id
• generated-app doctor verifies that the Azure Container Apps script still keeps explicit source-root, host-project, and az containerapp up --source seams for the current generated app id
• generated-app doctor verifies that the Kubernetes apply script still keeps explicit namespace, image placeholder, manifest-root, and kubectl kustomize plus kubectl apply seams for the current generated app id
• aligned generated scripts emit [ok], while drifted generated scripts emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, CLI package README, and template-pack README stay aligned with the same generated container deployment-script doctor story
• focused tooling coverage proves aligned generated scripts plus drifted container-image, Azure Container Apps, and Kubernetes deployment-script baselines on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the scaffolded deploy/container-image/publish-image.ps1, deploy/azure-container-apps/deploy-up.ps1, and deploy/kubernetes/apply.ps1 assets as part of the same generated-app bootstrap answer
• added generated deployment-script baseline checks that compare Dockerfile plus NuGet.config plus image placeholder plus preview/push flow seams, generated source-root plus host-project plus az containerapp up --source seams, and generated namespace plus image placeholder plus manifest-root plus kubectl kustomize/apply seams against the scaffolded doctor contract before teams run those scripts literally
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated container deployment-script doctor flow
• extended focused CLI and documentation coverage for aligned container deployment scripts plus drifted container-image, Azure Container Apps, and Kubernetes deployment-script baselines on the same doctor path

ENG-213 Generated app doctor deployment-asset alignment baseline

Status: done

Why:

• ENG-212 made generated-app doctor truthful about target-framework and publish-mode support posture, but external adopters could still drift the generated Dockerfile or remove shipped container deployment assets without the same command path warning them before container-image, Azure Container Apps, or Kubernetes work
• cephalon doctor --app-root <path> was already the generated-app bootstrap and support-contract command, so it was the sharpest place to verify the generated deployment assets instead of inventing another validation surface
• generated-app verification should answer whether the scaffolded container deployment shape still matches the generated host baseline before teams rely on hosted container deployment flows

Acceptance:

• cephalon doctor --app-root <path> validates the generated Dockerfile plus the shipped container-image, Azure Container Apps, and Kubernetes deployment assets
• generated-app doctor compares the generated Dockerfile SDK and ASP.NET base-image tags against the generated host target framework baseline
• stable-floor Dockerfile alignment emits [ok], readiness-lane Dockerfile alignment emits [warn], and missing or drifted deployment assets emit [error] with a failing doctor exit code
• the root README, getting-started guide, CLI docs, deployment-mode-support guide, CLI package README, and template-pack README stay aligned with the same generated deployment-asset doctor story
• focused tooling coverage proves aligned deployment assets, readiness-lane Dockerfile posture, missing deployment assets, and drifted Dockerfile image tags on the same doctor path

Completed work:

• extended DoctorCommand so generated-app doctor now validates the shipped Dockerfile plus the container-image, Azure Container Apps, and Kubernetes deployment assets as part of the generated-app bootstrap answer
• added generated Dockerfile baseline checks that compare SDK and ASP.NET base-image tags against the generated host target framework while preserving stable-floor versus readiness-lane posture in doctor output
• aligned README.md, docs/getting-started.md, docs/deployment-mode-support.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated deployment-asset doctor flow
• extended focused CLI and documentation coverage for aligned deployment assets, readiness-lane Dockerfile posture, missing deployment assets, and drifted Dockerfile base-image tags

ENG-209 Generated app bootstrap doctor follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-034 gave external adopters a truthful machine-level cephalon doctor, and ENG-037 plus ENG-038 gave generated apps the right package-source and publish-profile bootstrap assets, but a freshly scaffolded app still lacked one reusable command that proved those generated assets were still intact before the first restore, run, publish, or deployment replay
• without a generated-app-aware doctor path, teams still had to rediscover whether the scaffolded solution, Directory.Packages.props, NuGet.config cephalon source, seeded local feed or replaced external source, host project, and CephalonFolder.pubxml profile were all present before adoption docs would actually work on a clean machine
• external-adoption hardening should close the gap between “I can scaffold the app” and “I can trust the generated bootstrap shape” without inventing a second validation command outside Cephalon.Cli

Acceptance:

• cephalon doctor accepts --app-root <path> and reuses the existing machine-level readiness checks while adding generated-app bootstrap validation for the scaffolded app root
• generated-app doctor output validates the solution file, Directory.Packages.props Cephalon package baseline, NuGet.config cephalon source plus package-source mapping, seeded local package feed or non-local shared source, generated host project, and CephalonFolder.pubxml
• success output ends with copy/paste-ready generated-app next steps for Set-Location, dotnet restore, and dotnet run
• docs, CLI help text, tooling coverage, roadmap, and project memory stay aligned with the same generated-app bootstrap doctor path

Completed work:

• extended DoctorOptions, DoctorCommand, and CliApplication so cephalon doctor --app-root <path> now layers generated-app bootstrap validation on top of the existing machine-level SDK, runtime, and optional template-pack checks
• taught the generated-app doctor path to validate the scaffolded .slnx, Directory.Packages.props Cephalon package baseline, NuGet.config cephalon source plus package-source mapping, local ./.cephalon/packages feed or a replaced non-local source, generated host project, and Properties/PublishProfiles/CephalonFolder.pubxml, while returning generated-app-specific failure guidance and copy/paste-ready restore or run next steps
• aligned README.md, docs/getting-started.md, docs/components/cli.md, src/Cephalon.Cli/PACKAGE.md, and templates/Cephalon.TemplatePack/PACKAGE.md with the generated-app doctor flow
• added targeted CLI and documentation coverage for the new doctor option, generated-app bootstrap success path, generated-app bootstrap failure path, and aligned public help text, then verified the slice through focused tooling coverage plus regenerated reference docs

ENG-097 .NET 11 readiness baseline

Status: done Estimate: 5 Completed: April 18, 2026

Why:

• Cephalon now ships enough packages, templates, samples, and tooling that a future framework migration can no longer be treated as a one-line target-framework edit
• the repo needed one truthful way to assess .NET 11 compatibility without silently changing the stable net10.0 shipping floor enforced through global.json, scaffold defaults, templates, and docs
• deployment-mode claims such as trimming, Native AOT, and single-file needed an explicit contract so future support statements cannot outrun validation
• release validation still pointed at a deleted monolithic test project after the test-suite split, which left the current automation story out of sync with the real repo layout

Acceptance:

• the repo ships a dedicated .NET readiness script that records current SDK selection, higher-SDK readiness selection, target-framework audit results, and deployment-mode claim status
• release validation uses the split test projects that actually exist in the repository and emits a .NET readiness artifact alongside the rest of the release-validation outputs
• GitHub Actions includes a dedicated .NET 11 readiness lane that can validate future-SDK compatibility without editing the repo-root global.json
• scaffolding can round-trip a net11.0 target-framework override truthfully, including generated module manifests and container-image base tags
• docs, project memory, backlog, roadmap, package-publishing guidance, and support-claim language all stay aligned with the readiness-lane-not-baseline-shift model

Delivered:

• added scripts/validate-dotnet-readiness.ps1, which audits target frameworks, records repo-selected versus readiness-selected SDK versions, emits JSON plus Markdown reports, and can optionally build/test/publish from a temporary working directory outside the repo root so higher SDK validation does not inherit the global.json pin accidentally
• updated scripts/validate-release.ps1 to use the split Cephalon.Tests.Composition, Cephalon.Tests.Hosting, and Cephalon.Tests.Tooling projects, and to emit the readiness artifact as part of the repo-native release-validation flow
• updated .github/workflows/release-validation.yml so push now matches master as well as main, the normal release-validation matrix uploads readiness artifacts, and a dedicated .NET 11 readiness job now installs the 11.0.x SDK channel and runs the readiness script separately
• updated publish-reference-docs.ps1 and publish-package-artifacts.ps1 so higher-SDK readiness runs can execute their dotnet work from a temporary directory instead of always inheriting the repo-root SDK pin
• updated Cephalon.Scaffolding plus tooling tests so a net11.0 scaffold override now keeps the generated host project, module manifest, and Dockerfile base images aligned instead of freezing container images on 10.0
• added .NET 11 readiness docs plus compatibility, planning, package-publishing, and project-memory updates so framework and deployment-mode claims stay explicit and truthful

ENG-098 behavior-execution rate-limiting baseline

Status: done Estimate: 5 Completed: April 18, 2026

Why:

• phase 11 still listed broader non-route or non-ASP.NET Core rate-limiting semantics as the main resilience gap even though the shared behavior-dispatch layer already owned the rest of the behavior-execution resilience story
• the current behavior-execution runtime already enforced retry, timeout, circuit-breaker, and bulkhead, but rate limiting was still only a requested contract at that layer
• operators needed /engine/behavior-resilience, snapshot.BehaviorResiliencePolicies, and behavior-owned REST/OpenAPI 429 answers to reflect the same effective behavior-execution rate-limiting truth instead of depending only on ASP.NET Core endpoint middleware

Acceptance:

• BehaviorExecutionResilienceSelection and BehaviorExecutionResilienceOverrideSelection expose RateLimiting as part of the supported public contract
• Cephalon.Behaviors enforces behavior-execution rate limiting with the existing default plus override precedence and publishes the effective answer through IBehaviorResilienceRuntimeCatalog, /engine/behavior-resilience, and snapshot.BehaviorResiliencePolicies
• behavior-owned REST endpoints return truthful 429 payloads and OpenAPI metadata when the effective behavior-execution policy is rate-limited even without ASP.NET Core endpoint-level rate limiting
• targeted composition, hosting, and package-surface coverage prove the new runtime contract and rejection behavior

Delivered:

• Cephalon.Abstractions now extends BehaviorExecutionResilienceSelection plus BehaviorExecutionResilienceOverrideSelection with behavior-execution RateLimiting settings
• Cephalon.Engine now binds, validates, and projects behavior-execution rate-limiting defaults plus overrides through the same behavior+transport > behavior > transport > default precedence used by the other shared resilience strategies
• Cephalon.Behaviors now enforces the effective behavior-execution limiter in the shared dispatch pipeline and publishes truthful requested, explicit, inherited, disabled, and effective answers through /engine/behavior-resilience plus snapshot.BehaviorResiliencePolicies
• Cephalon.Behaviors.Http now keeps behavior-owned REST 429 translation truthful when both the ASP.NET Core endpoint limiter and the behavior-dispatch limiter target the same route, including the targeted override path where Engine:Resilience:RateLimiting:Overrides disables the endpoint policy so the behavior-owned answer can surface instead
• targeted composition, hosting, and package-surface coverage now prove the shared runtime contract, REST/OpenAPI behavior, and public package surface for the new phase-11 slice

ENG-099 generic behavior HTTP transport-native rate-limit envelopes

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• ENG-098 made behavior-execution rate limiting real in the shared dispatch pipeline, but the non-REST generic behavior HTTP bindings still flattened those shared limiter rejections into generic protocol failures
• phase 11 still needed the generic GraphQL, JSON-RPC, SSE, and WebSocket adapters to keep the same behavior-owned limiter truth without pretending every transport speaks the REST envelope
• runtime truth is stronger when one limiter-fault classification path can project protocol-native error shapes consistently across REST and the other shipped behavior HTTP transports

Acceptance:

• generic behavior HTTP GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings surface behavior-owned rate-limiting rejections through native protocol envelopes instead of generic transport failures
• the shared limiter-fault mapping keeps stable Cephalon codes plus 429 metadata consistent across REST and the other behavior HTTP transports
• targeted hosting coverage proves each shipped binding preserves its native wire contract under behavior-owned rate limiting
• docs, roadmap, backlog, and project memory narrow the remaining phase-11 gap truthfully to the broader non-REST resilience-envelope follow-through beyond the shipped 429/503 baseline

Delivered:

• Cephalon.Behaviors.Http now shares one internal limiter-fault mapper across REST, GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings so behavior-execution limiter rejections keep a stable Cephalon code plus statusCode = 429 metadata
• the GraphQL HTTP and GraphQL streaming bindings now return GraphQL-native errors[].extensions limiter details instead of flattening the shared dispatch rejection into a generic transport error
• the JSON-RPC binding now returns a protocol-native error response with a dedicated limiter code and structured limiter metadata instead of a generic failure payload
• the SSE and WebSocket bindings now emit native error events or frames that preserve the same behavior-owned limiter truth without wrapping those transports in the REST ResultModel contract
• targeted hosting, composition, and package-surface coverage now prove the new cross-transport limiter-envelope behavior and keep the package surface aligned with the shipped implementation

ENG-100 generic behavior HTTP transport-native timeout and circuit-breaker envelopes

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• ENG-099 closed the generic behavior HTTP rate-limiting gap, but behavior-owned timeout and circuit-breaker rejections still collapsed into generic failures for the non-REST behavior HTTP bindings
• phase 11 still needed the generic GraphQL, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket adapters to keep the same behavior-owned timeout and open-circuit truth without pretending every transport speaks the REST envelope
• runtime truth is stronger when one shared resilience-fault classification path can project timeout and circuit-breaker outcomes consistently across REST and the other shipped behavior HTTP transports

Acceptance:

• generic behavior HTTP GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings surface behavior-owned timeout and open-circuit rejections through native protocol envelopes instead of generic transport failures
• the shared resilience-fault mapping keeps stable Cephalon timeout and circuit-breaker codes plus 503 metadata consistent across REST and the other behavior HTTP transports
• targeted hosting coverage proves each shipped binding preserves its native wire contract under behavior-owned timeout and circuit-breaker rejections
• docs, roadmap, backlog, and project memory narrow the remaining phase-11 gap truthfully to broader non-REST resilience-envelope follow-through beyond the shipped 429/503 baseline

Delivered:

• Cephalon.Behaviors.Http now shares one resilience-fault mapper across REST, GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings so behavior-execution timeout and open-circuit rejections keep stable Cephalon codes plus statusCode = 503 metadata and optional retry-after timing
• the GraphQL HTTP and GraphQL streaming bindings now return GraphQL-native errors[].extensions timeout and open-circuit details instead of flattening shared dispatch failures into generic transport errors
• the JSON-RPC binding now returns a protocol-native -32053 service-unavailable server error while error.data preserves the stable Cephalon code, message, and optional retry-after detail for timeout and open-circuit answers
• the SSE and WebSocket bindings now emit native error events or frames that preserve the same behavior-owned timeout and circuit-breaker truth without wrapping those transports in the REST ResultModel contract
• targeted hosting, composition, and package-surface coverage now prove the new cross-transport timeout and circuit-breaker envelope behavior and keep the package surface aligned with the shipped implementation

Next configurable application-platform work

This feature wave is split into three non-overlapping workstreams so core contracts can freeze before package and generation follow-through:

• WS1 Engine core: ENG-046, ENG-047, and ENG-048
• WS2 Companion packs: ENG-049, ENG-050, ENG-051, and ENG-052
• WS3 CLI and scaffolding: ENG-053
• Validation lane: ENG-055 and ENG-056
• ENG-054 and ENG-057 stay later until the phase-8 golden path proves the contract

Cross-cutting success principle for this wave:

• every shipped slice should reduce ceremony for consumer apps by moving repeatable infrastructure, runtime wiring, and declarations into Cephalon configuration, companion packs, and scaffold conventions
• every shipped slice should reduce boilerplate without hiding operational truth, so teams can focus their hand-written code on business logic rather than framework plumbing

ENG-046 App-model taxonomy and catalog expansion baseline

Status: done Estimate: 5 Completed: April 4, 2026

Why:

• the engine already separates blueprints, patterns, and technologies, but the next feature wave mixes app shape, architecture style, data pattern, security mode, and deployment concerns in ways that will drift unless the taxonomy is frozen first
• the shipped catalogs stop short of Hexagonal, Layered, CleanArchitecture, DDD, CQRS, Outbox, EventSourcing, IdentityAccess, MultiTenancy, HybridCloudRuntime, ServiceMeshIntegration, and ServerlessHosting
• phase 8 needs one explicit answer for where each concept lives before code, docs, CLI defaults, or samples expand

Acceptance:

• new pattern ids and technology ids are frozen with aliases where needed
• shipped blueprints remain limited to app shapes instead of exploding into every architecture label
• planning, docs, scaffolding, and runtime catalogs can all reference the same ids
• public descriptors and XML comments explain the intent of every new id that enters the supported catalog

Delivered:

• built-in phase-8 pattern ids now cover hexagonal-architecture, layered-architecture, clean-architecture, domain-driven-design, cqrs, outbox, and event-sourcing
• built-in phase-8 technology ids now cover identity-access, multi-tenancy, hybrid-cloud-runtime, service-mesh-integration, and serverless-hosting
• pattern and technology descriptors now support aliases so config, planning, and scaffold guidance can speak one stable vocabulary without forcing only one spelling

ENG-047 Structured engine configuration and runtime surface baseline for data, identity, tenancy, audit, and messaging

Status: done Estimate: 8 Completed: April 4, 2026

Why:

• consumer apps need to turn these features on, off, or combine them through configuration without rewriting host startup
• the current Engine settings surface is too shallow for additive data, identity, tenancy, audit, and messaging packs with deeper options
• runtime snapshot and diagnostics surfaces should stay truthful once these new dimensions are introduced

Acceptance:

• structured Engine:Data, Engine:Identity, Engine:Tenancy, Engine:Audit, and Engine:Messaging sections exist with stable option names
• runtime and introspection surfaces expose the active phase-8 selections without binding the core to Entity Framework, Wolverine, or ASP.NET Core specifics
• config validation catches invalid combinations and missing prerequisites early
• host-specific APIs remain out of Cephalon.Abstractions

Delivered:

• EngineSettings now carries structured phase-8 settings for data, identity, tenancy, audit, and messaging
• resolved app profiles now surface phase-8 selections through Data, Identity, Tenancy, Audit, and Messaging
• phase-8 selection validation now catches invalid combinations such as read/write split without cqrs, outbox without outbox, or messaging provider selection without event-driven-integration

ENG-048 Host-agnostic data, authorization, tenancy, audit, and id contract baseline

Status: done Estimate: 13 Completed: April 4, 2026

Why:

• the requested phase-8 features need core primitives before any companion package can implement them cleanly
• the current abstractions do not yet carry first-class contracts for commands, queries, read/write stores, projections, outbox/inbox, authorization, tenant context, audit entries, or id generation
• if this contract slice drifts after package work starts, every downstream pack, scaffold, and sample will take breaking renames

Acceptance:

• Cephalon.Abstractions gains XML-commented public contracts for commands, queries, read/write stores, projections, outbox/inbox, authorization subjects/resources/policies, tenant context/resolution, audit entries, and id generation
• Cephalon.Engine gains matching catalog, descriptor, validation, and runtime-surface hooks without taking on provider-specific logic
• tests cover contract resolution plus runtime and introspection exposure
• host adapters stay out of the core contract slice

Delivered:

• Cephalon.Abstractions now includes host-agnostic Data, Authorization, Tenancy, Audit, and Ids contract families with XML-commented public types
• contract-focused composition tests, reference-doc smoke coverage, and an explicit Cephalon.Abstractions package-surface lock now cover the new exported API
• component guidance for Cephalon.Abstractions now documents the new phase-8 contract families
• Cephalon.Engine now exposes merged projection, inbox, outbox, and authorization-policy catalogs through /engine/projections, /engine/inboxes, /engine/outboxes, /engine/authorization-policies, and /engine/snapshot without binding the core to concrete providers
• projection ownership validation now fails fast when a module spoofs another module’s source id, and runtime tests cover both composition-time and ASP.NET Core introspection exposure

ENG-049 Relational Entity Framework CQRS, projections, outbox, and Sfid companion baseline

Status: done Estimate: 21 Completed: April 7, 2026

Why:

• Cephalon needs one honest data golden path before it claims support for many storage models
• the repo does not yet ship a first-class data/runtime baseline, and the requested feature wave explicitly calls for an Entity Framework-first path with provider escape hatches when official libraries are needed
• a relational baseline with CQRS read/write split, projections, outbox, and Sfid ids is the highest-leverage first slice
• the chosen id path should bind to the official Sfid.Net and Sfid.EntityFramework packages instead of a Cephalon-specific reimplementation

Acceptance:

• Cephalon.Data, Cephalon.Data.EntityFramework, and Cephalon.Ids.Sfid exist with clear package boundaries
• a relational Entity Framework read/write split, projection, and outbox baseline works through configuration and companion-pack registration instead of host-specific shortcuts
• runtime surfaces and observability hooks expose active stores, projections, outbox state, and id strategy truthfully
• Cephalon.Ids.Sfid wraps the official Sfid.Net generator, and the Entity Framework baseline integrates through Sfid.EntityFramework
• tests prove the baseline without over-claiming non-relational provider breadth yet

Delivered:

• Cephalon.Data now exists as a runtime-neutral command/query dispatch pack and registers default IReadStore / IWriteStore implementations backed by the existing handler abstractions
• Cephalon.Data.EntityFramework now exists as the first provider-backed data pack and registers single-context or split read/write Entity Framework Core DbContext roles through companion-pack registration instead of host-specific startup code
• Cephalon.Data.EntityFramework now also exposes an opt-in Entity Framework-backed inbox baseline that records processed InboxMessage rows through write-side contexts implementing IEntityFrameworkInboxContext
• Cephalon.Data.EntityFramework now also exposes an opt-in Entity Framework-backed outbox baseline that stages OutboxMessage rows through write-side contexts implementing IEntityFrameworkOutboxContext
• Cephalon.Ids.Sfid now exists as the first concrete ENG-049 slice and wraps the official Sfid.Net package through Cephalon.Abstractions.Ids.IIdGenerator
• the Sfid pack now supports explicit code-first options plus configuration-driven topology under Engine:Data:Ids:Sfid and exposes the official generator interface so Cephalon.Data.EntityFramework can use Sfid.EntityFramework
• Cephalon.Engine now exposes additive outbox catalogs through IOutboxCatalog, /engine/outboxes, and /engine/snapshot, and the Entity Framework pack publishes a truthful staged-only outbox descriptor instead of implying a dispatch runtime that does not exist yet
• Cephalon.Engine now also exposes additive inbox catalogs through IInboxCatalog, /engine/inboxes, and /engine/snapshot, and the Entity Framework pack publishes a truthful application-managed inbox descriptor instead of implying subscription execution semantics that do not exist yet
• when EventDrivenIntegration is active, the Entity Framework pack now also projects staged-only outbox producers into the event-driven-integration technology surface instead of claiming a fuller event dispatch runtime
• when EventDrivenIntegration is active, the Entity Framework pack now also projects application-managed inbox stores into the event-driven-integration technology surface instead of claiming handler dispatch or retry ownership that does not exist yet
• declared event-subscription metadata can now also report when an application-managed inbox store is available for idempotency follow-through without pretending that Cephalon.Eventing executes or retries those handlers yet
• when EventDrivenIntegration is active and a real outbox path exists, Cephalon.Eventing can now accept EventPublication requests through IEventPublisher and stage them into the active outbox instead of advertising publish support without a concrete handoff path
• Cephalon.Data.EntityFramework now also exposes an adapter-neutral Entity Framework-backed IEventDispatchStore so later shipped companion adapters can read pending staged outbox rows and apply durable dispatch outcomes without skipping around the Cephalon outbox contract
• package-surface tests, reference-doc tests, component docs, and solution/test-project wiring now include Cephalon.Data, Cephalon.Data.EntityFramework, and Cephalon.Ids.Sfid
• Cephalon.Data.EntityFramework now also implements IProjectionContributor and registers EF-backed projection descriptors when RegisterProjections is enabled, plus a data.projections.entity-framework capability and a projections runtime surface under data-management so operators can see active projection infrastructure through /engine/technology-surfaces and /engine/projections

Follow-up later:

• broader typed-id/documentation examples on top of the shipped Sfid.EntityFramework baseline
• fuller subscription/runtime linkage beyond the shipped staged publication and application-managed idempotency baselines

ENG-050 Eventing runtime uplift and Wolverine companion baseline

Status: done Estimate: 13 Completed: April 7, 2026

Why:

• the shipped Cephalon.Eventing surface already models channels and runtime answers, but it does not yet expose the fuller publisher/subscriber and outbox bridge story the next feature wave needs
• the outbox baseline is incomplete unless Cephalon can tell an operator what was published, subscribed, retried, or blocked
• Wolverine is the current shipped optional companion proof, MassTransit is the tracked-later strategic candidate, and the engine contract must stay runtime-neutral
• we need one clear companion proof instead of diluting the phase-8 baseline across several bus frameworks at once, but that proof must stay optional for consumer apps

Acceptance:

• event runtime contracts support publish and subscribe semantics plus outbox handoff and idempotent inbox follow-through
• Cephalon.Eventing surfaces active channels, subscriptions, and runtime state through the existing introspection model
• optional Cephalon.Eventing.Wolverine integration stays outside the engine core and aligns with the same contracts
• observability and diagnostics cover retries, handlers, and outbox bridge state

Delivered:

• Cephalon.Eventing now exposes public EventPublication and IEventPublisher contracts so active eventing runtimes can accept staged publication requests without leaking provider-specific APIs into Cephalon.Abstractions

• Cephalon.Eventing now also exposes public declared-subscription contracts and catalogs so eventing-enabled apps can surface subscription intent through the same pack without pretending that dispatch handlers are already active

• Cephalon.Eventing now registers an outbox-backed publisher only when EventDrivenIntegration is selected, publishing is enabled, and a real IOutbox implementation is present

• the eventing.publish capability is now truthful: it only appears when that outbox-backed handoff path exists, and its metadata now calls out handoff = outbox plus runtime-state availability without claiming a broker-owned dispatch runtime

• the event-driven-integration technology surface now includes event-subscriptions and event-publishers so operators can see declared subscription intent plus the active staged-publication path alongside event-channels and outbox producers

• declared subscription entries can now also link to hosted-execution descriptors, execution graphs, and runtime-story state through hosted-execution metadata, which gives a truthful application-managed execution answer without claiming that Cephalon.Eventing itself owns dispatch

• Cephalon.Eventing now also exposes public application-managed subscription runtime-state contracts through EventSubscriptionExecutionReport, EventSubscriptionRuntimeState, IEventSubscriptionRuntimeReporter, and IEventSubscriptionRuntimeCatalog, and event-subscriptions now projects that reported state plus operator-facing reported.* metadata alongside inbox, hosted-execution, execution-graph, and runtime-story linkage

• Cephalon.Eventing now also exposes public application-managed outbox-dispatch runtime-state contracts through EventDispatchExecutionReport, EventDispatchRuntimeState, IEventDispatchRuntimeReporter, and IEventDispatchRuntimeCatalog, and event-dispatches now projects that reported state plus operator-facing reported.* metadata on top of the staged outbox-backed publication path

• Cephalon.Eventing now also exposes the public EventDispatchItem plus IEventDispatchStore contract so later shipped companion adapters can read pending staged events and apply durable dispatch outcomes without binding the contract to Wolverine-specific APIs

• Cephalon.Eventing now publishes a stable diagnostics convention for staged publications plus application-managed subscription and publication-dispatch outcomes, and the engine now keeps technology runtime surfaces live enough for that reported state to show up after startup instead of freezing at the first catalog resolution

• the current Entity Framework outbox baseline now persists next_attempt_at_utc alongside dispatch_attempt_count and dispatched_at_utc, so the runtime-neutral dispatch-store contract can honor delayed retry intent instead of re-reading every retried row immediately

• Cephalon.Eventing.Wolverine now exists as a shipped optional companion slice with the eventing.wolverine capability plus the wolverine-adapter runtime surface, and it truthfully supports two modes: a host-wiring-only baseline that reports dispatchBridge = consumer-managed, plus an opt-in wolverine-managed durable staged-dispatch loop on top of IEventDispatchStore

• the event-dispatches technology surface now also projects configured dispatch-runtime descriptor metadata per outbox path, and the wolverine-adapter surface now aggregates latest outcome, retry-pending count, and report totals so operators can see both configuration truth and live runtime follow-through without stitching several surfaces together by hand

• Cephalon.Eventing.Wolverine now also contributes its own diagnostics convention so /engine/diagnostics and the runtime snapshot advertise the stable 4300-4305 Wolverine dispatch-loop event ids alongside the shared eventing diagnostics range

• Cephalon.Eventing.Wolverine now also exposes System.Diagnostics.ActivitySource (Cephalon.Eventing.Wolverine.Dispatch) and System.Diagnostics.Metrics.Meter instrumentation for the dispatch loop, with Activity spans per dispatch item (tagged with message_id, event_type, channel_id, dispatch_attempt, correlation_id, tenant_id) and counters for attempts, successes, failures, retries plus a histogram for dispatch duration in milliseconds — enabling OpenTelemetry-instrumented hosts to capture distributed traces and metrics without additional adapter code

• at that point eventing.subscriptions still exposed declared subscription descriptors rather than a pack-owned bus runner, and eventing.subscribe remained intentionally absent until a real subscription/dispatch runtime existed instead of over-claiming bus behavior; ENG-231 later adds the first truthful companion-managed case

• current direction: phase 8 treats Cephalon.Eventing.Wolverine as the first shipped optional companion proof, keeps MassTransit as the tracked-later candidate once the engine-owned contract and that proof are strong enough, and leaves MediatR, LiteBus, NServiceBus, and SlimMessageBus as consumer-owned coexistence choices unless a later bridge or adapter package is explicitly shipped

• coexistence rule: one flow should have one durable-messaging owner, so consumer apps should not layer Cephalon-managed durable messaging semantics and a second bus/runtime on the same publish/consume path Follow-up later:

• subscription/handler-execution truth beyond the current declarative and application-managed reporting model

• MassTransit or another companion adapter as a tracked-later strategic candidate once the engine-owned contract and current Wolverine proof are proven strongly enough

ENG-051 Identity and authorization companion baseline

Status: done Estimate: 13 Completed: April 7, 2026

Why:

• consumer apps need ready-to-use identity and authorization support, but Cephalon currently only has capability-boundary gating at the REST layer
• RBAC, ABAC, and policy-based evaluation need to be modelled as configuration-driven authorization modes instead of scattered host code
• ASP.NET Core-specific identity wiring should stay inside adapters, not inside Cephalon.Abstractions

Acceptance:

• Cephalon.Identity and Cephalon.Identity.AspNetCore exist with clear package boundaries
• authorization supports RBAC, ABAC, and policy-based evaluation through config plus host-agnostic contracts
• ASP.NET Core mapping to ClaimsPrincipal, schemes, and endpoint policies stays out of Cephalon.Abstractions
• runtime surfaces expose the active identity and authorization mode selection truthfully

Progress:

• Cephalon.Identity now exists locally as the host-agnostic identity companion pack with IdentityRuntimeOptions, declarative IdentityPolicyMetadataKeys, and AddIdentityAccess(...)
• the pack now registers a default metadata-driven IAuthorizationEvaluator that can enforce low-ceremony role, owner, tenant-boundary, and subject/resource/context attribute rules on top of the shipped authorization-policy contracts
• identity-access now projects an identity-authorization runtime surface that reports selected authorization modes, contributed policy counts, evaluator presence, and declarative convention support through the shared technology catalog
• /engine/diagnostics and /engine/snapshot can now advertise stable Cephalon.Identity diagnostic event ids 4400-4401 for allow/deny outcomes through the runtime diagnostics catalog
• Cephalon.Identity.AspNetCore now exists locally as a separate host adapter with AddCephalonIdentityAspNetCore(...), config-driven Engine:Identity:AspNetCore options, and a REST-only RequireCephalonAuthorization(...) endpoint helper that maps ClaimsPrincipal, route values, and request metadata into the shared Cephalon authorization contracts
• the ASP.NET Core adapter currently returns truthful 401 and 403 API responses and keeps authentication scheme ownership with the consumer host instead of pretending to replace ASP.NET Core authentication
• the REST adapter now also defers 401 and 403 responses to ASP.NET Core challenge/forbid behavior when the host or endpoint metadata already declares authentication schemes, including the low-ceremony WithCephalonAuthenticationSchemes(...) endpoint helper, which deepens scheme alignment without pushing authentication concerns into Cephalon.Abstractions
• the REST adapter now also respects AllowAnonymous endpoint metadata inside protected route groups, so consumer hosts can keep standard ASP.NET Core public-route semantics without bypassing Cephalon on the rest of the group
• direct request-factory coverage now locks custom claim-type selection, subject-id fallback behavior, and optional claim/route/query/header projection flags so config-driven ASP.NET Core identity adapter behavior does not silently drift
• the identity pack now also honors EnableDefaultEvaluator and EnableRuntimeSurface truthfully, so a disabled built-in evaluator falls back to a deterministic deny path instead of a missing-service failure, and an opt-out runtime surface disappears from the merged technology catalog instead of lingering as misleading metadata
• the ASP.NET Core adapter now also exposes a public [RequireCephalonAuthorization] attribute for controller and action boundaries, and it projects an identity-aspnetcore runtime surface so operator flows can see protected ASP.NET Core endpoint counts, active policy ids, integration modes, and AllowAnonymous overrides without guessing from code
• the ASP.NET Core adapter now also bridges authenticated ClaimsPrincipal data into Cephalon.Audit automatically when the audit pack is active and the host has not already supplied a custom IAuditActorAccessor, which gives low-ceremony audit actor resolution without pulling ASP.NET Core APIs into the host-agnostic audit pack
• package-surface tests, reference-doc tests, component docs, solution wiring, and hosting tests now cover both Cephalon.Identity and Cephalon.Identity.AspNetCore

ENG-052 Multi-tenancy and audit companion baseline

Status: done Estimate: 13 Completed: April 7, 2026

Why:

• multi-tenancy plus audit/history are part of the promised consumer-ready surface, not incidental sample code
• tenant resolution, membership, domain mapping, and audit trails need additive contracts that remain configurable and overridable
• this slice needs to align with identity and data surfaces instead of inventing separate side channels

Acceptance:

• Cephalon.MultiTenancy and Cephalon.Audit exist with clear package boundaries
• tenant context/resolution plus audit and history contracts are configurable, optional, and overridable
• baseline support covers tenant-aware runtime state and audit/history event capture without forcing one storage model
• observability and runtime answers surface the active tenancy and audit configuration truthfully

Delivered:

• Cephalon.MultiTenancy now exists locally as the first host-agnostic tenancy companion pack with MultiTenancyRuntimeOptions, AddMultiTenancy(...), a configuration-driven ITenantResolver, and an ambient ITenantContextAccessor
• the pack now contributes a truthful tenant-resolution runtime surface under multi-tenancy plus stable 4500-4502 diagnostics-catalog entries for resolved, defaulted, and missed tenant answers
• the built-in configuration-driven resolver now keeps explicit tenant-id, tenant-key, and host-name misses as misses instead of defaulting into another tenant, which closes the first tenant-bleed risk in the v1 baseline
• the built-in resolver can now also be disabled explicitly through EnableDefaultResolver, and the runtime surface reports that state instead of pretending the configuration-driven resolver is always active
• solution wiring, package-surface tests, reference-doc tests, and component docs now cover Cephalon.MultiTenancy
• Cephalon.Audit now exists locally as the first narrow host-agnostic audit companion pack with AuditRuntimeOptions, AuditMetadataKeys, AddAudit(...), a default IAuditRecorder, a default ambient IAuditActorAccessor, and an application-managed in-memory writer baseline
• Cephalon.Audit now contributes a dedicated audit-store catalog through IAuditStoreCatalog, /engine/audit-stores, and /engine/snapshot instead of overloading technology surfaces or observability-only answers
• the audit baseline now honors AuditRuntimeOptions.EnableInMemoryWriter / Engine:Audit:EnableInMemoryWriter end to end across service-collection, ASP.NET Core, and Worker host paths, and the runtime audit-store catalog now stays aligned with that choice instead of pretending the memory-backed store is active when it is not
• the audit pack now also preserves additive consumer audit-store contributions when AddAudit() is active, so disabling the built-in in-memory writer only removes audit-default and no longer clobbers consumer/runtime-provided audit stores from /engine/audit-stores or /engine/snapshot
• the audit baseline now ships stable 4600-4601 diagnostics-catalog entries for successful and failed audit-entry writes, plus targeted composition, hosting, package-surface, and reference-doc coverage
• the audit baseline now also gets a truthful low-ceremony actor bridge in ASP.NET Core hosts: when Cephalon.Identity.AspNetCore is active, authenticated principal data can populate ambient audit actors automatically, while custom audit actor accessors still remain authoritative and /engine/technology-surfaces/identity-access reports whether that bridge is active, merely available, or not configured

Follow-up later:

• audit follow-through beyond the narrow recording baseline: durable persistence providers, query/replay, retention policies
• tenant membership and domain-mapping enrichment beyond the current configuration-driven resolver

ENG-053 CLI, scaffolding, template-pack, and sample alignment for phase 8

Status: done Estimate: 13 Completed: April 7, 2026

Why:

• phase 8 is not a real adoption surface until cephalon new, scaffold plans, template starters, and samples emit the same story
• the shipped scaffolds already imply clean and CQRS-friendly conventions and should be extended instead of replaced
• generation should follow the frozen ids, config sections, and package names instead of driving them
• phase 8 only delivers the intended low-ceremony value if generated hosts and starter assets remove repetitive setup and let consumer apps begin closer to business logic

Acceptance:

• Cephalon.Cli, Cephalon.Scaffolding, Cephalon.TemplatePack, and at least one golden-path sample align with the phase-8 config and package contract
• generated hosts emit the structured Engine sections plus the right package hints and folder conventions for clean, CQRS, and DDD-flavored apps
• test projects carry TDD and BDD-friendly starter conventions without moving those ideas into engine runtime contracts
• scaffold, runtime, template, and sample semantics stay aligned through tests and docs
• generated starters keep ceremony low by centralizing common Cephalon wiring, avoiding repeated bootstrap code, and leaving the remaining hand-written code focused on domain and business behavior

Delivered:

• Cephalon.Scaffolding now emits canonical phase-8 ids in generated Engine settings instead of older display-name strings, and generated hosts now carry structured Engine:Data, Engine:Identity, Engine:Tenancy, Engine:Audit, and Engine:Messaging sections
• phase-8-aware scaffold package hints now add the low-ceremony companion-pack baseline for Cephalon.Data, Cephalon.Ids.Sfid, Cephalon.Eventing, Cephalon.Eventing.Wolverine, Cephalon.Identity, Cephalon.Identity.AspNetCore, Cephalon.MultiTenancy, and Cephalon.Audit when the selected patterns and technologies require them
• generated Program.cs output now centralizes the common phase-8 host wiring through builder.AddCephalon(engine => ...), optional builder.AddCephalonIdentityAspNetCore(), and additive pack registrations so consumer apps do not need to hand-write the same bootstrap code before they reach business logic
• generated hosts, templates, and the showcase sample now adopt the split Configurations/Add*.json plus Configurations/{group}/{Environment}.json convention while still leaving appsettings.json and appsettings.{Environment}.json available as normal host-level overrides
• Cephalon.TemplatePack starter apps now also carry canonical ids, structured phase-8 sections, and a narrow low-ceremony Sfid plus Audit baseline so dotnet new does not drift behind cephalon new
• REST-enabled scaffold, template-pack, and blueprint-sample outputs now also align on behavior-backed public REST ownership by default: generated public REST starter modules use RestBehaviorModuleBase plus Cephalon.Behaviors.Http and MapProfile<TBehavior>() instead of ModuleBase plus IEndpointModule, while non-REST output stays on the generic module baseline
• adoption-quality starter samples now mirror that same narrow Sfid plus Audit baseline through canonical settings and additive host wiring, and hosting coverage now locks those sample app-model answers through /engine/app-model
• generated test projects now start with Architecture/CompositionSmokeTests.cs plus per-feature Features/*BehaviorSpecifications.cs placeholders so TDD/BDD-friendly starter conventions land through scaffolding and CLI output without turning testing style into a runtime contract

Follow-up later:

• broader phase-8 sample/template documentation follow-through
• further starter polish and additional transport-specific template variations

ENG-054 Provider-family and hybrid-runtime follow-through

Status: done Estimate: 80 Completed: April 7, 2026

Why:

• the requested feature wave eventually reaches vector, document, graph, search, time-series, ledger, service-mesh, hybrid-cloud, and serverless follow-through, but the contract is not proven yet
• shipping provider breadth before the golden path would over-claim support and destabilize the core
• this work should stay explicit and adoption-driven after the initial phase-8 baseline lands

Acceptance:

• non-relational provider families are split into explicit companion packages with clear scope and no leakage back into Cephalon.Engine or Cephalon.Abstractions
• HybridCloudRuntime, ServiceMeshIntegration, and ServerlessHosting remain additive technology follow-through instead of new blueprints or engine-core branches
• docs, runtime surfaces, and observability stay truthful about which provider families and deployment runtimes are actually shipped
• expansion work starts only after the relational-first phase-8 golden path is complete

Delivered:

• Sprint 25 — MongoDB (document-store): Cephalon.Data.MongoDB (IOutbox + IInbox backed by MongoDB collections, idempotent staging via unique index on MessageId, data.mongodb / data.document-store capabilities) + Cephalon.EventSourcing.MongoDB (IEventStore with optimistic concurrency via compound unique index on StreamId+StreamVersion) — MongoDB.Driver 3.4.0 in CPM, 12 integration tests via EphemeralMongo — commit f94dc28 · 599/599 tests
• Sprint 26 — Redis (key-value-store): Cephalon.Data.Redis (IOutbox backed by Redis Hash + Sorted Set with KeyNotExists transaction condition, IInbox backed by Redis Set with naturally idempotent SADD, data.redis / data.key-value-store capabilities) + Cephalon.EventSourcing.Redis (IEventStore via Redis Streams XADD/XRANGE, optimistic pre-insert version check) — StackExchange.Redis 2.8.16 in CPM, 8 composition tests — 607/607 tests
• Sprint 27 — Neo4j (graph-store): Cephalon.Data.Neo4j (IOutbox + IInbox backed by Neo4j graph nodes, idempotent staging via Cypher MERGE on messageId, data.neo4j / data.graph-store capabilities) + Cephalon.EventSourcing.Neo4j (IEventStore with IS NODE KEY constraint on streamId+streamVersion) — Neo4j.Driver 6.0.0, 8 composition tests — 615/615 tests
• Sprint 28 — Cassandra (wide-column-store): Cephalon.Data.Cassandra (IOutbox + IInbox backed by Cassandra tables, idempotent staging via LWT INSERT IF NOT EXISTS, data.cassandra / data.wide-column-store capabilities) + Cephalon.EventSourcing.Cassandra (IEventStore with composite PK on stream_id+stream_version, LWT concurrency detection) — CassandraCSharpDriver 3.22.0, 8 composition tests — 624/624 tests
• Sprint 29 — ClickHouse (analytics-store): Cephalon.Data.ClickHouse (IOutbox + IInbox backed by ClickHouse ReplacingMergeTree tables, eventual idempotency via ORDER BY deduplication + FINAL reads, data.clickhouse / data.analytics-store capabilities) + Cephalon.EventSourcing.ClickHouse (IEventStore with MergeTree ORDER BY, application-layer optimistic concurrency) — ClickHouse.Driver 1.0.2, 8 composition tests — 632/632 tests
• Sprint 30 — Elasticsearch + OpenSearch (search-store): Cephalon.Data.Elasticsearch (IOutbox + IInbox backed by Elasticsearch indices, op_type=create idempotency with 409 swallow, data.elasticsearch / data.search-store capabilities) + Cephalon.EventSourcing.Elasticsearch (IEventStore with compound document id {streamId}#{streamVersion}) + Cephalon.Data.OpenSearch (OpenSearch.Client mirror, data.opensearch / data.search-store capabilities) + Cephalon.EventSourcing.OpenSearch (OpenSearch event store mirror) — Elastic.Clients.Elasticsearch 8.17.0 + OpenSearch.Client 1.8.0, 8 composition tests — 640/640 tests
• Sprint 31 — Qdrant + NATS (vector-store + ledger-store): Cephalon.Data.Qdrant (IOutbox + IInbox backed by Qdrant vector collections with 1D dummy vectors and payload-field storage, deterministic UUID from message ID via SHA-256, data.qdrant / data.vector-store capabilities) + Cephalon.EventSourcing.Qdrant (IEventStore with compound point-ID hash, ScrollAsync-based replay) + Cephalon.Data.Nats (IOutbox + IInbox backed by NATS JetStream KV, NatsKVCreateException idempotency, data.nats / data.ledger-store capabilities) + Cephalon.EventSourcing.Nats (IEventStore via JetStream KV with zero-padded keys {streamId}/{version:D20}) — Qdrant.Client 1.17.0 + NATS.Net 2.7.3, 8 composition tests — 648/648 tests
• all 9 non-relational provider families shipped as companion packs with no changes to Cephalon.Engine or Cephalon.Abstractions
• each provider family delivers both Cephalon.Data.{Provider} and Cephalon.EventSourcing.{Provider} packages
• full component-guide docs for all 18 packages (9 data + 9 event-sourcing)
• HybridCloudRuntime, ServiceMeshIntegration, and ServerlessHosting remain tracked-later until explicit adoption cases

Follow-up later:

• service-mesh and serverless runtime follow-through remain later until explicit adoption cases
• hybrid-cloud deployment runtime beyond the shipped provider breadth

ENG-055 Phase 8 validation, benchmark, and runtime-truth matrix

Status: done Estimate: 8 Completed: April 7, 2026

Why:

• AGENTS requires new runtime features to stay observable, testable, benchmarkable, and truthful through runtime introspection
• the current phase-8 plan introduces many new contracts and companion packages, but without a dedicated validation lane the repo could accidentally claim support before benchmark, diagnostics, or test coverage catches up
• the fastest path is not enough on its own; Cephalon needs a repeatable quality bar that survives future package expansion

Acceptance:

• phase-8 features have an explicit validation matrix that covers config validation, runtime introspection, diagnostics, benchmark guardrails, and representative happy-path plus failure-path tests
• benchmark additions or updates land where hot paths or composition/runtime/scaffolding risks materially change
• runtime snapshot, diagnostics, runtime-story, and package/technology surfaces stay truthful for every shipped phase-8 slice
• release and repo validation guidance stays aligned with the new quality bar

Delivered:

• scripts/validate-phase8-conventions.ps1 now exists as the focused validation replay for the shipped phase-8 baseline, covering settings/profile truth, host-agnostic contracts, runtime surfaces, relational data and Sfid, eventing and Wolverine, identity/tenancy/audit, ASP.NET Core adapter follow-through, low-ceremony starter output, and package/reference-doc/documentation truth
• scripts/validate-release.ps1 now also runs that focused phase-8 suite by default, and the release-validation guidance now documents -SkipPhase8Conventions as the explicit escape hatch instead of relying on the wider repo test pass alone
• adoption docs and package readmes now keep the phase-8 starter-test harness truthful by explicitly calling out Architecture/CompositionSmokeTests.cs plus per-feature Features/*BehaviorSpecifications.cs, and documentation coverage tests now guard that story
• Cephalon.Benchmarks now also carries explicit phase-8 composition, runtime-lifecycle, and scaffolding scenarios alongside the earlier baseline paths, and the guardrail catalog has been refreshed against the current BenchmarkDotNet output so --validate-guardrails can police both the existing baseline and the shipped low-ceremony phase-8 path truthfully
• the repo-native release-validation entry point now passes again with the phase-8 benchmark filters after aligning reference-module and signed-package minimumEngineVersion baselines with the current repo package version, scoping discovery-based tests away from invalid phase-8 negative fixtures plus Entity Framework-only test modules, and making the runtime-route hosting test declare a real event subscription before it expects eventing.subscriptions

Follow-up later:

• benchmark expansion for runtime hot paths: data layer dispatch, event sourcing, behavior dispatch, authorization, multi-tenancy, outbox, transports (tracked under ENG-059)

ENG-056 Phase 8 docs, XML comments, component-guide, and reference-doc alignment

Status: done Estimate: 8 Completed: April 5, 2026

Why:

• the repo treats hand-authored docs plus public XML comments as part of the product surface, not post-hoc extras
• phase 8 adds new public contracts and companion-package surfaces that will be harder to understand and safer to misuse unless docs and IntelliSense stay aligned from the start
• adoption quality depends on docs, XML comments, component guides, and reference-doc publishing telling the same truth as the code

Acceptance:

• new public phase-8 contracts ship with XML comments suitable for the supported reference-doc pipeline
• relevant component docs under docs/components/ and hand-authored adoption guidance are updated for the shipped phase-8 slices
• Cephalon.ReferenceDocs, hosted reference-doc guidance, and documentation indexes stay aligned if the supported public API surface changes
• checked-in docs/reference/ output stays aligned with the current Cephalon.ReferenceDocs generator through a repo-native drift guard instead of manual spot checks alone
• docs stay explicit about what is shipped now versus what remains later, especially around event sourcing, provider breadth, hybrid runtime, service mesh, and serverless claims

Delivered:

• the checked-in docs/reference/ bundle has been regenerated for the current phase-8 assembly set
• the tooling test lane now guards bundle drift by comparing the checked-in output against the current Cephalon.ReferenceDocs generator after normalizing volatile timestamps
• the top-level adoption docs plus blueprint sample READMEs now describe the shipped phase-8 starter baseline truthfully
• component docs for all phase-8 companion packs (data, eventing, identity, multi-tenancy, audit, Sfid) are published

ENG-057 Event-sourcing follow-through baseline

Status: done Estimate: 21 Completed: April 5, 2026

Why:

• EventSourcing belongs in the phase-8 taxonomy, but the repo does not yet have a truthful delivery baseline for event-store persistence, stream replay, projection rebuilds, or operational answers around those flows
• folding event sourcing into the early relational-first golden path would risk over-claiming a harder storage and lifecycle model before the underlying CQRS, outbox, and runtime contracts settle
• keeping this explicit protects the planning truth and leaves room for a stronger, adoption-driven design later

Acceptance:

• event-store persistence, stream versioning, replay, projection rebuild, and operational/runtime-introspection answers are modelled explicitly instead of implied by taxonomy alone
• any shipped event-sourcing implementation stays additive through companion packages and does not force a storage model into Cephalon.Engine or Cephalon.Abstractions
• docs, runtime surfaces, and observability clearly distinguish shipped event-driven integration from shipped event-sourcing support
• work starts only after the relational-first phase-8 golden path is complete and its contracts are stable

Delivered:

• Cephalon.EventSourcing now exists as the runtime-neutral event-sourcing contract package with IEventStore (GetVersionAsync, AppendAsync, ReadStreamAsync), IDomainEvent, EventStreamConcurrencyException, and System.Text.Json serialization conventions
• Cephalon.EventSourcing.EntityFramework now exists as the relational-first event-store provider with optimistic concurrency via unique constraint on (StreamId, StreamVersion), IAsyncEnumerable stream replay, and AddCephalonEntityFrameworkEventSourcing() builder extension
• 9 additional non-relational event-store providers shipped through ENG-054: MongoDB, Redis, Neo4j, Cassandra, ClickHouse, Elasticsearch, OpenSearch, Qdrant, and NATS — each implementing IEventStore with provider-appropriate concurrency enforcement and stream replay
• all event-sourcing implementations stay in companion packages with no changes to Cephalon.Engine or Cephalon.Abstractions
• IBehaviorContext.EventStore wiring in the ABT foundation (ENG-058 M6) connects behaviors to the active event-store provider
• full component-guide docs for all 10 event-store providers

ENG-059 Runtime hot-path benchmark expansion

Status: done Estimate: 13 Completed: April 7, 2026

Why:

• the current benchmark suite covers composition, runtime lifecycle, scaffolding, and HTTP logging (~10 benchmarks across 4 classes), but runtime hot paths that execute on every request remain unmeasured
• data layer dispatch (IReadStore/IWriteStore), event sourcing (IEventStore append/read/hydrate), behavior dispatch (BehaviorDispatcher), authorization evaluation, multi-tenancy resolution, and outbox staging have zero benchmark coverage
• without baseline measurements and guardrails for these paths, performance regressions in the most frequently executed code will go undetected
• the comprehensive audit on April 7, 2026 identified ~25-29% critical-path coverage as the primary production-readiness gap

Acceptance:

• benchmark coverage reaches critical runtime hot paths: data layer dispatch, event sourcing, behavior dispatch pipeline
• benchmark coverage reaches high-priority paths: authorization evaluation, multi-tenancy resolution, outbox staging, transport handlers
• guardrail thresholds defined for all new benchmark scenarios
• scripts/validate-release.ps1 validates the expanded guardrail catalog

Delivered:

• HotPath/DataDispatchBenchmarks.cs: IReadStore query dispatch (DispatchQuery), IWriteStore void command dispatch (DispatchCommand), result-returning command dispatch (DispatchCommandWithResult) — 8192 ops/iteration, warm-cache steady-state measurement
• HotPath/BehaviorDispatchBenchmarks.cs: BehaviorDispatcher.DispatchAsync with frozen-dictionary lookup and compiled delegate invocation (DispatchBehavior) — 8192 ops/iteration with stub catalog/registry
• HotPath/AuthorizationEvaluationBenchmarks.cs: MetadataDrivenAuthorizationEvaluator RBAC allow path (EvaluateRbacAllow) and deny path (EvaluateRbacDeny) — 8192 ops/iteration with policy module contributing RBAC policies
• HotPath/TenantResolutionBenchmarks.cs: ConfiguredTenantResolver by explicit tenant id (ResolveByTenantId), hostname domain matching (ResolveByHostName), and default-tenant fallback (ResolveDefaultTenant) — 8192 ops/iteration with 3-tenant directory
• HotPath/EventSourcingBenchmarks.cs: in-memory IEventStore single-event append (AppendSingleEvent), 100-event stream read (ReadStream), version lookup (GetStreamVersion) — 4096 ops/iteration with in-memory event store
• HotPath/OutboxStagingBenchmarks.cs: in-memory IOutbox enqueue staging (StageOutboxMessage) — 4096 ops/iteration with in-memory outbox
• Support/BenchmarkHotPathTypes.cs: data layer stubs (BenchmarkQuery/Command/ResultCommand + handlers), behavior stubs (EchoBenchmarkBehavior, StubBehaviorContext/Catalog/TypeRegistry), authorization policy module (BenchmarkAuthorizationPolicyModule), InMemoryBenchmarkEventStore, InMemoryBenchmarkOutbox, BenchmarkDomainEvent
• guardrail catalog expanded from 10 to 23 entries covering all new hot-path benchmarks
• GuardrailValidatorTests updated for 23-entry catalog
• benchmark project now references Cephalon.Behaviors for behavior dispatch measurement

Follow-up later:

• transport handler benchmarks — requires HTTP test infrastructure per transport (partially covered by existing AspNetCoreRequestLoggingBenchmarks)

ENG-060 Engine-owned database topology and runtime catalog baseline

Status: done Estimate: 8

Why:

• the current Engine:Data section is intentionally logical and too shallow to own physical database roles, migration targeting, or durable history routing
• the shipped provider-pack baseline is strong enough that topology drift is now the next real risk: read/write, outbox, and history layouts can become sample- or pack-specific instead of a stable engine contract
• Cephalon differentiates most when runtime topology is introspectable and configuration-driven across companion packs, not when every provider invents its own host section

Acceptance:

• Engine:Databases exists as the engine-owned physical-topology contract separate from the existing logical Engine:Data section
• named database roles such as Write, Read, and History can be validated and surfaced through runtime introspection without leaking EF Core or ASP.NET Core specifics into Cephalon.Abstractions
• outbox and audit-history follow-through can target a named role instead of duplicating provider/connection settings ad hoc
• /engine/snapshot and a dedicated database catalog answer the active role, provider-family, and topology truthfully

Delivered so far:

• Engine:Databases now exists as the engine-owned physical-topology contract with Runtime, Write, Read, Outbox, History, and nested Migrations
• the contract now projects into EngineSettings, AppProfile.Databases, /engine/databases, /engine/app-model, and /engine/snapshot
• the engine now also ships an additive IDatabaseRoleCatalog so /engine/database-roles and snapshot.DatabaseRoles expose requested versus resolved roles, UseRole truth, consumers, co-location, and additive metadata over the same topology contract
• the first validation baseline now covers role-pattern alignment, migration-target validity, and mutually exclusive named versus inline connection settings
• the contract now also supports narrow dependent role references through UseRole so Outbox and History can explicitly reuse the concrete write role while layering local schema/runtime overrides

Remaining follow-through inside ENG-060:

• broaden the current one-step UseRole -> write contract only when provider packs and runtime surfaces can keep requested versus resolved roles truthful
• deepen the runtime answer beyond the current role catalog when provider packs begin contributing richer per-role metadata
• keep the contract aligned across docs, templates, and samples as the provider follow-through lands

Planned follow-through:

• add engine-owned configuration types and validation for role-based database topology
• keep provider-family standards intact inside the topology model instead of flattening every store into one fake universal connection shape
• keep the runtime role catalog additive and host-agnostic instead of making provider packs or hosts invent competing topology answers
• keep Engine:Data focused on logical selection (Provider, ReadWriteSplit, Outbox, Ids) while Engine:Databases owns physical deployment detail

ENG-061 Role-aware relational runtime and migration orchestration baseline

Status: done Estimate: 13

Why:

• Cephalon.Data.EntityFramework currently proves one honest relational path, but it still relies on host-owned DbContext registration instead of an engine-owned role topology
• migration policy is still mostly a host concern, which keeps production deployment guidance, startup apply behavior, and operator truth spread across samples instead of the engine product surface
• mandatory ReadDbContextBase / WriteDbContextBase inheritance would be a weaker engine contract than role-aware registration helpers plus optional shared schema slices and interceptors

Acceptance:

• Cephalon.Data.EntityFramework consumes engine-owned database roles instead of inventing a second physical-topology config model
• relational hosts can keep one shared DbContext or split read/write/history contexts while still aligning with the same role contract
• migration configuration can target named roles, startup apply remains explicit, and deploy-time bundles or scripts become the documented production path
• runtime answers expose active relational role wiring, outbox routing, and migration targeting truthfully

Delivered so far:

• Cephalon.Data.EntityFramework now ships topology-aware AddEntityFrameworkData(...) overloads that resolve the engine-owned write and optional read roles directly from Engine:Databases
• the Entity Framework pack now publishes role and migration-policy metadata through the data-management/database-roles runtime surface
• Engine:Databases:Migrations:ApplyOnStartup now activates a generic-host hosted service inside Cephalon.Data.EntityFramework that applies startup schema creation or migrations for the registered write and optional read DbContext roles
• the same migration-registration primitives now also back truthful history-role execution when a companion pack registers a dedicated history DbContext, which is how Cephalon.Audit.EntityFramework plugs into the baseline
• the same baseline now resolves explicit dependent role references for outbox and history, and the runtime surface reports requested versus resolved roles when those references are active
• the showcase sample now demonstrates configured WriteDb, ReadDb, and HistoryDb root roles for Docker-backed runs while using an explicit Outbox -> write role reference instead of duplicating write connection settings

Remaining follow-through inside ENG-061:

• add dedicated outbox role execution only when a companion pack can back that role with truthful DbContext ownership
• keep marker interfaces, model-builder extensions, and interceptors as the preferred reusable primitives
• treat convenience DbContext base classes as optional later DX helpers rather than the primary contract
• add CLI, docs, and sample guidance for separate migrations projects plus bundle/script-first production deployment when multiple relational DbContext models share one physical database

ENG-062 Durable audit-history provider baseline

Status: done Estimate: 8

Why:

• the current Cephalon.Audit baseline is intentionally truthful, but it only solves low-ceremony recording and in-memory storage
• audit history, retention, and role-aware persistence need a durable baseline before Cephalon can claim a real operational story around tenant-aware change history
• durable history should not pull storage assumptions back into Cephalon.Audit; it should stay additive and configurable through the same engine-owned topology contract used by data and outbox follow-through

Acceptance:

• durable audit history can be turned on or off through Engine:Audit without changing module code
• the first durable history path targets a named database role instead of hardcoding its own connection model
• runtime audit-store answers expose whether history is in-memory only, durable, or disabled
• the baseline keeps replay/export follow-through explicit without pretending those surfaces already exist

Delivered:

• Cephalon.Audit.EntityFramework now ships as the first durable audit-history provider pack on the relational golden path
• Engine:Audit:History now projects into EngineSettings, AppProfile.Audit, /engine/app-model, and /engine/snapshot
• IAuditStoreRuntimeContributor now lets additive provider packs publish durable audit-store descriptors without widening Cephalon.Audit into a mandatory storage abstraction
• durable audit history now targets a named database role, defaults to history, can be redirected through Engine:Audit:History:DatabaseRole, and publishes its runtime truth through /engine/audit-stores and /engine/snapshot
• durable audit history now also consumes the engine-owned UseRole contract when the selected database role is a dependent alias, and audit-store runtime metadata now exposes requested versus resolved roles
• the showcase sample now records durable audit history through the new provider pack while keeping dedicated configured WriteDb, ReadDb, and HistoryDb roles for Docker-backed runs plus a truthful zero-setup fallback outside Docker
• the same baseline now includes Engine:Audit:History:Retention, the first engine-owned retention pass, IAuditHistoryReader, /engine/audit-history, and showcase-facing audit-history read endpoints

Remaining follow-through inside ENG-062:

• add replay follow-through and richer export formats on top of the shipped durable write, read, export, and retention path
• add non-relational audit-history providers only when they can stay truthful and additive
• keep ASP.NET Core actor bridging and tenant context additive without turning the audit pack into a host-specific storage abstraction

ENG-063 Durable audit-history query/read and retention operator surface

Status: done Estimate: 5

Why:

• the first durable audit-history baseline proved write-path persistence, but operators and sample consumers still lacked a truthful read/query surface
• retention policy also needed to become a real engine-owned contract instead of a doc-only promise
• Cephalon needs one host-agnostic reader contract that durable providers can implement without forcing REST or host APIs back into Cephalon.Audit

Acceptance:

• durable provider packs can expose filtered, paged reads through a host-agnostic reader contract
• ASP.NET Core hosts expose operator-facing audit-history routes only when a durable reader is active
• durable audit-history retention validates and projects through EngineSettings, AppProfile, and runtime metadata truthfully
• the showcase sample demonstrates public audit-history routes without pretending every host must expose them

Delivered:

• Cephalon.Abstractions now exposes IAuditHistoryReader, AuditHistoryQuery, AuditHistoryQueryResult, and AuditHistoryEntry
• Cephalon.Audit.EntityFramework now ships a filtered-page reader plus retention hosted service on top of the durable write path
• /engine/audit-history and /engine/audit-history/{auditEntryId} now expose operator-facing reads when a durable reader is registered
• the showcase sample now publishes /api/v1/showcase/audit/history and /api/v1/showcase/audit/history/{auditEntryId} through a dedicated module-owned REST surface
• engine runtime registration now supplies baseline TimeProvider and ILogger<T> services so timer-driven or logged companion services can activate cleanly in code-first hosts and tests

Remaining follow-through inside ENG-063:

• add replay workflows over durable history without turning the reader contract into a report engine
• add richer operator filters or aggregation endpoints only when they stay provider-truthful and benchmarkable

ENG-064 Durable audit-history export baseline

Status: done Estimate: 5

Why:

• the shipped durable audit-history reader closed the write-only gap, but operators and samples still lacked a truthful export surface for offline analysis, incident handoff, or controlled data movement
• Cephalon needed one additive export contract that durable provider packs can implement without turning Cephalon.Audit into a report engine or locking the platform to one host shape
• the first export slice needed to stay narrow, benchmarkable, and replay-friendly without prematurely claiming full replay semantics

Acceptance:

• durable provider packs can expose a bounded export stream through a host-agnostic exporter contract
• ASP.NET Core hosts expose operator-facing audit-history export routes only when export is explicitly enabled
• the showcase sample documents and exercises a public audit-history export endpoint over a real durable provider path
• runtime metadata and app-model projection expose whether export is enabled and how many entries one export may stream

Delivered:

• Cephalon.Abstractions now exposes IAuditHistoryExporter, AuditHistoryExportRequest, and AuditHistoryExportSelection
• Engine:Audit:History:Export now projects into EngineSettings, AppProfile.Audit, /engine/app-model, and /engine/snapshot
• Cephalon.Audit.EntityFramework now ships the first bounded export baseline and publishes truthful export metadata through /engine/audit-stores
• /engine/audit-history/export now exposes operator-facing NDJSON export when a durable exporter is registered and export is enabled
• the showcase sample now publishes /api/v1/showcase/audit/history/export through a dedicated module-owned REST surface
• Cephalon.AspNetCore now ships AuditHistoryExportHttpResponseExtensions so application modules can reuse the NDJSON response wiring instead of rewriting it

Remaining follow-through inside ENG-064:

• add replay flows on top of the shipped export baseline without conflating replay with reporting
• add richer export formats such as CSV or provider-native batch handoff only when they stay truthful and benchmarkable
• add non-relational export-capable audit-history providers only when they can implement the same bounded contract honestly

ENG-065 Truthful dependent database-role reference baseline

Status: done Estimate: 5

Why:

• the first Engine:Databases baseline could describe dependent roles through UseRole, but the runtime story still blurred requested versus resolved truth once Outbox or History reused write
• additive provider packs and operator surfaces needed one honest answer for co-located roles before broader role graphs could be considered safely
• the showcase sample needed to prove that one codebase can keep distinct root roles while intentionally aliasing dependent infrastructure roles

Acceptance:

• dependent Outbox and History roles can explicitly reuse write through UseRole
• runtime metadata reports requested versus resolved roles truthfully for the first dependent-role baseline
• the showcase sample demonstrates explicit Outbox -> write routing while keeping a dedicated configured HistoryDb root role for Docker-backed runs

Delivered:

• Engine:Databases now supports the narrow UseRole -> write baseline for dependent Outbox and History targets
• Cephalon.Data.EntityFramework and Cephalon.Audit.EntityFramework now surface requested versus resolved role truth when those references are active
• runtime metadata now reports dependent-role co-location instead of pretending every configured role is always a separate physical target
• the showcase sample now keeps WriteDb, ReadDb, and HistoryDb as explicit configured roots for Docker-backed runs while proving Outbox -> write routing end to end

Remaining follow-through inside ENG-065:

• broaden role graphs beyond UseRole -> write only when runtime surfaces, provider packs, and migration guidance can stay truthful
• add richer operator answers for co-located roles, schema overrides, and provider-family nuance without overfitting the contract to Entity Framework

ENG-066 Engine-owned database-role catalog and operator surface

Status: done Estimate: 5

Why:

• /engine/databases projected the raw topology contract, but operators and provider packs still lacked one engine-owned answer for resolved runtime roles
• requested versus resolved role truth, role consumers, co-location, and audit-history metadata needed a host-agnostic contract that did not depend on one provider pack’s runtime surface
• the broader topology story needed a stable public abstraction before more providers or role-health follow-through could build on it cleanly

Acceptance:

• Cephalon.Abstractions exposes a public database-role catalog contract for resolved runtime roles
• /engine/database-roles, /engine/database-roles/{databaseRoleId}, and /engine/snapshot expose the same operator-facing role truth
• the catalog reports requested versus resolved roles, UseRole, provider, connection mode, schema, merged runtime tuning, consumers, and co-located role metadata
• durable audit-history metadata can attach to the selected logical role without coupling the role catalog to a specific provider pack

Delivered:

• IDatabaseRoleCatalog and DatabaseRoleDescriptor now ship in Cephalon.Abstractions as the engine-owned runtime catalog contract
• Cephalon.Engine now projects resolved database roles into snapshot.DatabaseRoles with requested versus resolved role truth, UseRole metadata, consumers, co-located roles, and merged runtime tuning
• ASP.NET Core hosts now expose /engine/database-roles plus /engine/database-roles/{databaseRoleId} as the operator-facing role catalog
• audit-history selection now enriches the selected role with provider, export, and retention metadata so operator answers stay cross-pack and truthful
• the showcase sample and hosting tests now prove the catalog end to end, including Outbox -> write, a dedicated configured HistoryDb role for Docker-backed runs, zero-setup in-memory fallback outside Docker, and snapshot alignment

Remaining follow-through inside ENG-066:

• add live database-role health, migration-execution progress, and richer provider-specific diagnostics only when they can stay truthful and additive
• broaden the catalog beyond the current named roles only when the engine can preserve deterministic ordering, validation, and operator clarity

ENG-067 Engine-owned database-migration catalog and zero-setup sample follow-through

Status: done Estimate: 5

Why:

• Engine:Databases:Migrations projected requested policy, but operators and hosts still lacked one engine-owned answer for logical migration targets and their runtime state
• provider packs needed a public additive migration catalog contract before more packs could report planned, running, succeeded, failed, or unsupported targets consistently
• the showcase sample still hid those surfaces outside Docker because it skipped Entity Framework pack registration entirely in zero-setup runs

Acceptance:

• Cephalon.Abstractions exposes a public database-migration catalog contract for logical migration targets
• /engine/database-migrations, /engine/database-migrations/{databaseMigrationId}, and /engine/snapshot expose the same operator-facing migration truth
• Cephalon.Data.EntityFramework contributes migration targets and runtime status through the engine-owned catalog
• the showcase sample keeps database-role, migration, and durable audit-history surfaces active in local/test runs without requiring Docker

Delivered:

• IDatabaseMigrationCatalog, IDatabaseMigrationContributor, and DatabaseMigrationDescriptor now ship in Cephalon.Abstractions as the engine-owned migration catalog contract
• Cephalon.Engine now projects resolved migration targets into snapshot.DatabaseMigrations and ASP.NET Core hosts now expose /engine/database-migrations plus /engine/database-migrations/{databaseMigrationId}
• Cephalon.Data.EntityFramework now contributes planned/running/succeeded/failed migration truth through the engine-owned catalog instead of keeping execution state inside hosted services only
• the showcase sample now always wires Entity Framework data plus durable audit history, uses PostgreSQL in Docker mode, rewrites Write / Read / History to unique in-memory targets outside Docker, keeps separate write, read, and history migration targets truthful, and proves /engine/database-migrations plus the public audit-history routes end to end in zero-setup runs

Remaining follow-through inside ENG-067:

• add bundle/script orchestration metadata and deploy-time execution truth when Cephalon grows beyond hosted-service or manual migration stories
• add provider-native migration diagnostics only when they stay additive and do not overfit the public catalog to Entity Framework

ENG-068 Live database-role health and provider-aware migration diagnostics baseline

Status: done Estimate: 3

Why:

• the engine-owned database-role catalog exposed logical topology truth, but it still stopped short of proving whether the active provider pack could actually connect and what the current migration pressure looked like at runtime
• dependent roles such as outbox -> write needed a truthful way to inherit resolved-role runtime health without inventing a second physical runtime surface
• the engine-owned migration catalog now answered target identity and status, but it still stopped short of telling operators what bundle/script/update path they should actually run next
• the database-topology roadmap already treats bundle/script-first deployment as the production path, so that guidance needed to become runtime-introspectable instead of living only in docs
• provider packs needed a truthful way to publish runtime health, migration diagnostics, and deploy-time command templates without pretending the engine already orchestrates bundle generation or execution end to end

Acceptance:

• the engine-owned database-role catalog can carry provider-contributed live runtime health and migration diagnostics per logical role
• dependent UseRole targets can inherit resolved-role runtime truth without lying about their logical identity
• the engine-owned migration catalog can carry provider-added operator-facing command templates per logical target
• Cephalon.Data.EntityFramework publishes connectivity plus pending-migration diagnostics for registered DbContext roles and bundle/script/update guidance for registered migration targets
• /engine/database-roles, /engine/database-migrations, and /engine/snapshot keep the same health/diagnostic/guidance truth visible to operators and tooling
• docs distinguish live provider diagnostics plus command-template guidance from actual bundle/script generation or execution orchestration

Delivered:

• Cephalon.Data.EntityFramework now probes registered DbContext roles live through the engine-owned database-role runtime surface, publishing connectivity outcome, provider identity, pending migration counts, applied migration counts, and last probe metadata without leaking Entity Framework APIs into Cephalon.Abstractions
• the resolved database-role catalog now lets dependent UseRole targets such as outbox -> write inherit resolved-role runtime truth while staying explicit that the logical role is still outbox
• Cephalon.Abstractions now ships DatabaseMigrationCommandDescriptor, and DatabaseMigrationDescriptor now carries a typed Commands collection instead of forcing deploy-time guidance into ad-hoc metadata keys only
• Cephalon.Data.EntityFramework now decorates logical migration targets with role-health/runtime metadata and publishes dotnet ef bundle/script/update templates per target, marking bundle/script as production-recommended
• DatabaseMigrationCommandDescriptor now also carries typed operator metadata such as ToolId, ExecutionCategory, and WorkingDirectoryHint, and the EF pack now populates those fields while preserving additive metadata for compatibility
• DatabaseMigrationDescriptor now also carries a typed RecommendedExecutionOrder hint, the EF pack now publishes recommended write / read / history / outbox sequencing additively, and both the engine-owned migration catalog plus the showcase playbook now consume that shared order instead of re-encoding target ids locally
• DatabaseMigrationDescriptor now also mirrors resolved-role runtime truth through typed RoleHealthState, RoleHealthDescription, RoleMigrationState, RoleMigrationDescription, and RoleObservedAtUtc fields, while Cephalon.Data.EntityFramework continues to preserve the older roleHealthState / roleMigrationState metadata keys for compatibility
• the showcase sample plus hosting/composition tests now prove live role health, inherited role runtime, migration-runtime metadata, command templates, durable read-projection jobs, and the adoption-quality /api/v1/showcase/system/database-topology operator projection end to end through /engine/database-roles, /engine/database-migrations, snapshot, and a dedicated Database Topology section on /showcase that now also derives operator insights for aligned versus drifting topology state, preserves rich migration-command guidance instead of collapsing the engine-owned descriptors to raw strings, adapts those published templates into runnable sample commands from the repo root, presents the same target set as an ordered sample migration playbook backed by engine-published order hints before the lower-level migration table, answers readiness directly as ready, attention, or blocked, publishes an ordered operator action plan for what to do next, exposes /api/v1/showcase/system/database-topology/brief as a shareable Markdown handoff derived from the same live projection, and now exposes /api/v1/showcase/system/database-topology/handoff as a downloadable self-describing package that bundles a package README.md, a machine-readable handoff-manifest.json, the brief, and the raw projection payload
• the showcase sample now also exposes those typed migration role-runtime fields directly in its database-topology projection and /showcase operator console, using metadata previews only for provider-specific extras instead of stable engine-owned fields
• component docs, architecture guidance, backlog, roadmap, and project memory now call out that live provider diagnostics and command templates are shipped while true bundle/script generation or execution orchestration remains a later slice

Remaining follow-through inside ENG-068:

• add bundle/script artifact generation or execution orchestration only when the engine can keep provider behavior truthful and additive
• add richer provider-native diagnostics, per-step migration telemetry, or adaptive/provider-specific probe cadence only when the public catalog can stay stable across providers

ENG-086 Database-role probe freshness policy and stable operator projection follow-through

Status: done Estimate: 3

Why:

• ENG-068 proved live provider diagnostics, but the database-role catalog still re-probed every registered DbContext on every read, which made operator routes noisier and more expensive than needed
• probe freshness needed to live in the engine-owned topology contract instead of becoming an Entity Framework-only hidden cache
• the showcase operator projection needed to make live-versus-cached answers visible directly so the sample stayed a proving consumer of the engine contract instead of compensating for it with ad-hoc metadata parsing

Acceptance:

• Engine:Databases:Runtime and AppProfile.Databases.Runtime expose a non-negative RoleProbeFreshnessSeconds contract, with 0 as the explicit disable-caching answer
• runtime selection merging keeps shared and role-specific freshness overrides truthful across direct roles and dependent UseRole targets
• Cephalon.Data.EntityFramework caches role-probe results additively, invalidates them when migration runtime state changes, and publishes stable runtime metadata for live-versus-cache answers
• showcase projection/UI/config plus hosting/composition tests make the stronger engine contract visible end to end
• docs, backlog, roadmap, project memory, and GitHub tracking distinguish the shipped freshness-window baseline from later probe telemetry or cadence follow-through

Delivered:

• DatabaseRuntimeSettings, DatabaseRuntimeSelection, AppProfileFactory, DatabaseTopologyRoleResolver, and the runtime role catalog now carry RoleProbeFreshnessSeconds as an engine-owned runtime contract, including 0 as the explicit no-cache answer
• Cephalon.Data.EntityFramework now resolves effective probe freshness from the merged engine/runtime contract, defaults to a 30-second provider freshness window when none is configured, caches live probe results per logical role, and invalidates cached answers when migration execution updates the same role state
• EF-backed role runtime metadata now keeps probeCacheEnabled, probeFreshnessSeconds, probeFreshnessOrigin, probeSource, probeFreshUntilUtc, and probeAgeSeconds visible alongside existing connectivity and migration-pressure diagnostics
• the showcase sample now configures the engine-owned freshness policy in grouped Configurations/Engine/Databases/* files, projects probe freshness/live-versus-cache truth through /api/v1/showcase/system/database-topology, and shows observed time, probe source, probe age, and fresh-until timing directly in /showcase
• composition and hosting coverage now prove runtime-contract binding, role-resolution merge behavior, EF cache invalidation, and operator-projection output without relying on sample-only hidden state
• database-topology, component docs, roadmap, backlog, and project memory now call out the shipped probe-freshness baseline while keeping finer-grained probe cadence, telemetry, and broader provider parity as later work

Remaining follow-through inside ENG-086:

• add adaptive or provider-native probe cadence only when it can stay explicit in the shared engine/runtime contract
• add richer per-step migration telemetry and broader provider-native operational diagnostics without overfitting the public catalog to one provider

ENG-088 Engine-owned database-topology operational summary and advisory surface

Status: done Estimate: 5

Why:

• the engine-owned role and migration catalogs kept the raw truth available, but operators and hosts still lacked one canonical engine-owned answer for whether the overall topology was ready, needed attention, or was blocked
• the showcase sample was still re-aggregating readiness and insight logic locally from raw catalogs, which weakened the engine-first boundary and made the sample responsible for an answer that should belong to the engine
• hosts and automation needed one stable posture route for summary, advisories, and ordered operator actions without depending on showcase-only projection logic

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic operational snapshot contract for database-topology posture
• Cephalon.Engine projects one summary, advisory set, and ordered operator action plan from the database-role and database-migration catalogs and includes it in the runtime snapshot
• ASP.NET Core hosts expose /engine/database-topology as the canonical posture route
• the showcase sample consumes the engine-owned posture for readiness and engine-level insights, while keeping only read-model drift/backlog follow-through local
• docs, backlog, roadmap, project memory, and GitHub tracking all stay aligned with the new engine-first ownership line

Delivered:

• Cephalon.Abstractions now ships DatabaseTopologyOperationalAction, DatabaseTopologyOperationalActionPlan, DatabaseTopologyOperationalSummary, DatabaseTopologyOperationalAdvisory, DatabaseTopologyOperationalSnapshot, and IDatabaseTopologyOperationalSnapshotProvider as the host-agnostic posture contract
• Cephalon.Engine now computes engine-owned database-topology posture from the resolved role and migration catalogs, projects it into snapshot.DatabaseTopology, and keeps summary status, advisories, remediation categories, source ids, and ordered action links explicit instead of trapping that answer in a sample
• ASP.NET Core hosts now expose /engine/database-topology directly, so operators and tooling can read one canonical Ready / Attention / Blocked answer plus ordered next actions without rebuilding it from lower-level catalogs first
• the showcase sample now uses the engine-owned posture as the baseline for readiness, advisory insights, and the engine portion of its ordered action plan, keeps read-model drift/catch-up/disabled-sync logic as the only sample-specific follow-through, and now carries the engine route through browser config, operator links, UI metadata, brief output, and handoff source-route metadata
• composition, hosting, and package-surface coverage now prove the new posture contract, showcase consumption path, and exported package surface end to end

Remaining follow-through inside ENG-088:

• add an explicit engine-owned unknown or unprobed role-health posture only when provider packs can keep that semantics truthful across more than the current EF-backed baseline

ENG-089 Database-topology action-plan showcase follow-through and contract truthfulness

Status: done Estimate: 3

Why:

• the engine-owned database-topology action-plan contract had already landed in the shared abstractions and runtime snapshot, but the showcase sample still re-shaped the engine portion of the ordered action plan locally from raw role and migration state
• the sample projection, UI, and brief output were still collapsing engine-owned action metadata instead of preserving stable categories plus source role and migration ids
• package-surface and planning docs needed to stay truthful about the public action-plan types that now ship from Cephalon.Abstractions

Acceptance:

• the showcase sample consumes the engine-owned database-topology action plan as the baseline for ordered operator steps
• showcase-specific read-model sync actions append to the same ordered plan without re-deriving engine-owned role or migration remediation logic
• the sample projection, browser console, and operator brief preserve engine-owned action categories plus source role and migration ids
• package-surface, composition, and hosting tests prove the action-plan contract and showcase follow-through
• docs, roadmap, backlog, project memory, and GitHub tracking stay aligned with the shipped action-plan contract

Delivered:

• the showcase database-topology projection now maps snapshot.DatabaseTopology.ActionPlan directly into its ordered operator action plan and only appends read-model sync follow-through when the sample needs extra guidance
• the projection, browser console, and Markdown brief now preserve engine-owned action categories plus source role and migration ids instead of collapsing those stable fields away
• package-surface coverage now treats DatabaseTopologyOperationalAction plus DatabaseTopologyOperationalActionPlan as part of the documented Cephalon.Abstractions contract surface
• composition and hosting coverage now assert engine-owned action-plan counts, categories, and source ids end to end through /engine/database-topology, snapshot.DatabaseTopology, and /api/v1/showcase/system/database-topology
• database-topology, engine component docs, roadmap, backlog, and project memory now describe the action-plan contract truthfully instead of documenting only summary plus advisories

ENG-090 Engine-owned database-migration playbook surface and showcase adoption

Status: done Estimate: 3

Why:

• the engine-owned migration catalog already exposed recommended order hints and command descriptors, but the one ordered migration playbook still lived in showcase-only projection logic
• operators and tooling still lacked one engine route and one snapshot field that answered the ordered production-versus-manual migration guidance directly
• the showcase sample needed to consume that engine-owned ordered answer and keep only repo-root command adaptation plus read-model follow-through as local logic

Acceptance:

• Cephalon.Abstractions exposes host-agnostic ordered migration-playbook contracts for runtime and operator consumption
• Cephalon.Engine publishes /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook as the canonical ordered migration answer over the lower-level migration catalog
• the engine-owned playbook carries generated counts, ordered steps, startup-apply truth, resolved-role identity, current status, and selected production-versus-manual command guidance per target
• the showcase sample consumes that engine-owned playbook directly for ordered migration guidance and keeps only sample-specific command adaptation plus read-model follow-through local
• composition, hosting, and package-surface tests prove the new contract and showcase adoption path end to end
• docs, roadmap, backlog, project memory, and GitHub tracking stay aligned with the shipped engine-first ownership line

Delivered:

• Cephalon.Abstractions now ships DatabaseMigrationOperationalPlaybook, DatabaseMigrationOperationalStep, and IDatabaseMigrationOperationalPlaybookProvider as the host-agnostic ordered migration-playbook contract
• Cephalon.Engine now computes one ordered playbook from the resolved migration catalog, selects production-recommended and manual/direct command paths when available, projects that answer into snapshot.DatabaseMigrationPlaybook, and keeps generated time plus target counts explicit instead of trapping the playbook in a sample
• ASP.NET Core hosts now expose /engine/database-migration-playbook, so operators and tooling can read the same ordered answer without reconstructing it from /engine/database-migrations
• the showcase sample now consumes the engine-owned playbook for its ordered migration guidance, keeps direct links to the new engine route in the browser config, brief, and handoff metadata, and limits local logic to repo-root runnable command adaptation plus sample-only read-model follow-through
• composition coverage now proves the playbook provider and runtime snapshot contract, hosting coverage now proves the route plus showcase consumption path, and package-surface coverage now locks the exported abstractions surface
• database-topology, engine component docs, roadmap, backlog, project memory, and showcase docs now describe the playbook contract truthfully as engine-owned runtime surface rather than sample-derived sequencing

ENG-091 Shared physical database migration coordination surface and showcase follow-through

Status: done Estimate: 3

Why:

• the engine-owned role catalog and migration playbook could already describe logical targets, but they did not yet expose when multiple logical roles or migration targets actually shared one physical database target
• operators still lacked one engine-owned coordination answer for shared-database migration work, which made it too easy to miss deploy-time risk when write and read reused one connection target or when dependent roles inherited the same database
• the showcase sample needed to consume that shared-target truth from the engine instead of inferring it locally in the operator projection, brief, or UI

Acceptance:

• Cephalon.Abstractions exposes host-agnostic physical-target identity and shared-target coordination fields on the shipped database-role and migration-playbook contracts
• Cephalon.Engine groups logical roles by physical target, projects that truth through /engine/database-roles plus snapshot.DatabaseRoles, and exposes shared-target migration coordination through /engine/database-migration-playbook plus /engine/database-topology
• the engine-owned playbook carries coordination counts, per-step physical-target identity, coordinated migration ids, and operator hints for shared targets
• the engine-owned topology posture adds advisory and action-plan guidance when pending or failed logical migration work spans one physical database target
• the showcase sample consumes the engine-owned physical-target and shared-target coordination answers directly in its JSON projection, browser console, Markdown brief, and handoff package
• composition and hosting coverage prove the shared-target contract end to end, and package-surface coverage locks the exported abstractions surface
• docs, roadmap, backlog, project memory, and GitHub tracking stay aligned with the shipped engine-first ownership line

Delivered:

• DatabaseRoleDescriptor now carries PhysicalTargetId, PhysicalTargetDisplayName, and PhysicalCoLocatedRoles, while DatabaseMigrationOperationalStep now carries PhysicalTargetId, PhysicalTargetDisplayName, CoordinatedMigrationIds, CoordinationHint, and RequiresPhysicalTargetCoordination; DatabaseMigrationOperationalPlaybook now also carries CoordinationRequiredTargetCount
• Cephalon.Engine now computes stable physical-target grouping across configured database roles, projects that role truth through the engine-owned role catalog, and uses it to enrich the engine-owned migration playbook and topology posture
• /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook now surface shared-target coordination counts, per-step coordinated partner targets, and operator-facing coordination hints without requiring a sample or host to rebuild that answer
• /engine/database-topology plus snapshot.DatabaseTopology now surface shared-physical-target migration-coordination advisories and ordered action-plan entries when pending or failed logical migration work spans one physical database
• the showcase sample now consumes those engine-owned answers directly in /api/v1/showcase/system/database-topology, /showcase, /api/v1/showcase/system/database-topology/brief, and /api/v1/showcase/system/database-topology/handoff, while keeping only sample-specific read-model follow-through local
• validation now covers the new shared-target path through composition tests 4/4, hosting tests 60/60, and package-surface tests 52/52
• database-topology, engine component docs, Entity Framework component docs, roadmap, backlog, project memory, and showcase docs now describe the shipped shared-target coordination contract truthfully

ENG-092 Shared physical database migration execution-group playbook follow-through

Status: done Estimate: 3

Why:

• the engine-owned migration playbook already surfaced shared-target coordination truth, but operators still had to regroup ordered steps mentally into physical-target batches before planning deploy-time work
• the playbook contract still lacked one aggregate answer for shared physical targets, so status, production guidance coverage, and startup/manual posture were only visible per logical step
• the showcase sample needed to consume that grouped answer directly so the proving surface stayed aligned with the engine instead of inventing its own physical-target batch summary

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic execution-group contract on the shipped migration-playbook surface
• Cephalon.Engine groups ordered logical playbook steps by physical target and publishes that grouped answer through /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook
• each execution group carries stable physical-target identity, aggregate status, grouped migration ids, requested and resolved role ids, target counts, production/manual/startup counts, and shared-target coordination hints when relevant
• the showcase sample consumes those execution groups directly in its JSON projection, browser UI, Markdown brief, and handoff package instead of re-grouping logical targets locally
• composition, hosting, and package-surface tests prove the execution-group contract end to end
• docs, roadmap, backlog, project memory, and GitHub tracking stay aligned with the shipped engine-first ownership line

Delivered:

• DatabaseMigrationOperationalPlaybook now carries ExecutionGroupCount, CoordinationRequiredGroupCount, and ExecutionGroups, while Cephalon.Abstractions now also ships DatabaseMigrationOperationalExecutionGroup
• Cephalon.Engine now computes physical-target execution groups from the ordered migration playbook, including aggregate status precedence, grouped migration ids, requested versus resolved role ids, coverage counts, and coordinated shared-target hints
• /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook now surface grouped physical-target execution batches without requiring hosts or tooling to rebuild that answer from lower-level migration rows
• the showcase sample now consumes those engine-owned execution groups directly in /api/v1/showcase/system/database-topology, /showcase, /api/v1/showcase/system/database-topology/brief, and /api/v1/showcase/system/database-topology/handoff, while keeping only repo-root command adaptation plus read-model follow-through local
• validation now covers the new grouped execution path through composition tests 4/4, hosting tests 60/60, and package-surface tests 52/52
• database-topology, engine component docs, Entity Framework component docs, roadmap, backlog, project memory, and showcase docs now describe the shipped execution-group contract truthfully

ENG-093 Shared physical database migration execution-group command-set follow-through

Status: done Estimate: 3

Why:

• the engine-owned migration playbook already grouped logical targets into physical-target execution batches, but operators still had to open each ordered step to reconstruct the exact production or manual command set for one shared-database batch
• execution groups exposed coverage counts, status, and coordination hints, yet they did not publish the grouped command paths that tooling or operators actually need to review before deploy-time work
• the showcase sample needed to consume those grouped command sets directly so the proving surface stayed aligned with the engine instead of rebuilding batch-level command guidance from per-step rows

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic grouped-command contract on the shipped execution-group surface
• Cephalon.Engine publishes grouped production and manual command sets per physical-target execution group through /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook
• each grouped command entry carries execution order, logical migration target id, requested and resolved role ids, and the selected command descriptor for that path
• the showcase sample consumes those grouped command sets directly in its JSON projection, browser UI, Markdown brief, and handoff package instead of reconstructing them from ordered steps
• composition, hosting, and package-surface tests prove the grouped command-set contract end to end
• docs, roadmap, backlog, project memory, and GitHub tracking stay aligned with the shipped engine-first ownership line

Delivered:

• Cephalon.Abstractions now also ships DatabaseMigrationOperationalExecutionGroupCommand, while DatabaseMigrationOperationalExecutionGroup now carries grouped ProductionCommands and ManualCommands
• Cephalon.Engine now projects the selected per-step production/manual commands back into their physical-target execution groups with stable execution ordering and target-role identity
• /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook now surface one grouped command-set answer per physical target instead of forcing operators or tooling to rebuild that batch guidance from lower-level rows
• the showcase sample now consumes those engine-owned grouped command sets directly in /api/v1/showcase/system/database-topology, /showcase, /api/v1/showcase/system/database-topology/brief, and /api/v1/showcase/system/database-topology/handoff, while keeping only repo-root command adaptation plus read-model follow-through local
• validation now covers the new grouped command-set path through composition tests 4/4, hosting tests 60/60, and package-surface tests 52/52
• database-topology, engine component docs, Entity Framework component docs, roadmap, backlog, project memory, and showcase docs now describe the shipped grouped command-set contract truthfully

ENG-094 Shared physical database migration execution-group command-batch follow-through

Status: done Estimate: 3

Why:

• the engine-owned migration playbook already surfaced grouped command sets per physical-target batch, but operators and tooling still had to copy or stitch those commands together manually when they needed one combined batch answer for deploy-time work
• execution groups already knew stable command order, tool ids, and working-directory hints, yet the contract still lacked one deterministic combined command-batch template for the selected production and manual paths
• the showcase sample needed to consume that engine-owned batch answer directly so the proving surface stayed aligned with the engine instead of rebuilding one multiline copy/paste view locally

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic command-batch contract on the shipped execution-group surface
• DatabaseMigrationOperationalExecutionGroup publishes combined production and manual command-batch templates derived from the selected grouped commands
• each combined command batch preserves playbook order plus target, command-id, tool-id, and working-directory truth for the selected path
• the showcase sample consumes those combined command batches directly in its JSON projection, browser UI, Markdown brief, and handoff package while keeping only repo-root command adaptation local
• composition, hosting, and package-surface tests prove the combined command-batch contract end to end
• docs, roadmap, backlog, project memory, and GitHub tracking stay aligned with the shipped engine-first ownership line

Delivered:

• Cephalon.Abstractions now also ships DatabaseMigrationOperationalExecutionGroupCommandBatch, while DatabaseMigrationOperationalExecutionGroup now carries ProductionCommandBatch and ManualCommandBatch
• the execution-group contract now derives one deterministic multiline combined command template per selected production or manual path, including stable target ids, command ids, tool ids, and working-directory hints
• /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook now surface one combined command-batch answer per physical-target path instead of forcing operators or tooling to stitch grouped commands together locally
• the showcase sample now consumes those engine-owned combined command batches directly in /api/v1/showcase/system/database-topology, /showcase, /api/v1/showcase/system/database-topology/brief, and /api/v1/showcase/system/database-topology/handoff, while keeping only repo-root command adaptation plus read-model follow-through local
• validation now covers the new combined command-batch path through composition tests 4/4, hosting tests 60/60, and package-surface tests 52/52
• database-topology, engine component docs, Entity Framework component docs, roadmap, backlog, project memory, and showcase docs now describe the shipped combined command-batch contract truthfully

ENG-095 Phase 12 migration-pattern taxonomy baseline

Status: done Estimate: 2

Why:

• phase 12 explicitly called for strangler-fig and backend-for-frontend, but the built-in engine pattern taxonomy still could not express those choices through the same app-model vocabulary as other shipped patterns
• architecture docs and planning guidance still had to describe those phase 12 patterns as recommendations instead of stable runtime descriptors
• teams adopting Cephalon incrementally need those pattern ids available through configuration, /engine/patterns, and AppProfile.Patterns before routing or client-binding follow-through lands

Acceptance:

• BuiltInPatterns exposes stable strangler-fig and backend-for-frontend descriptors with aliases, tags, and architecture classification
• configuration-driven app-profile selection resolves those new pattern ids and aliases through the same engine-owned path used by existing patterns
• ASP.NET Core hosts surface the new descriptors through /engine/patterns and the runtime app model
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the descriptor-only scope, while remaining honest that IStranglerFigRouter and client-binding policy follow-through are later slices

Delivered:

• Cephalon.Engine now ships BuiltInPatterns.StranglerFigPattern and BuiltInPatterns.BackendForFrontendPattern as architecture-level descriptors
• the engine now resolves StranglerFig, Strangler, BackendForFrontend, and BFF through the same built-in pattern catalog used by configuration-driven app-model selection
• targeted composition and hosting coverage now prove both alias resolution and /engine/patterns plus /engine/app-model visibility for the new phase 12 taxonomy entries
• architecture inventory, architecture recommendations, engine component docs, roadmap, backlog, and project memory now describe the shipped descriptor baseline truthfully while keeping router and client-binding follow-through explicitly planned

ENG-096 Phase 12 strangler-fig runtime contract baseline

Status: done Estimate: 3

Why:

• after ENG-095, phase 12 could name strangler fig but still could not express real migration-route ownership or request resolution through engine-owned contracts
• modules and hosts still lacked a reusable, host-agnostic way to declare which path prefixes were under migration and which Cephalon module owned the modern boundary
• operator tooling had no direct runtime answer for the active strangler-fig route catalog or which target would win for a specific request

Acceptance:

• Cephalon.Abstractions ships host-agnostic strangler-fig route contribution, runtime-catalog, request, resolution, and router contracts
• Cephalon.Engine composes both host-added and module-contributed strangler-fig routes, auto-selects the strangler-fig pattern when routes exist, and projects the route catalog into the runtime snapshot
• ASP.NET Core hosts expose direct operator routes for the active strangler-fig route catalog and one request-resolution probe
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the contract-first/runtime-only scope while remaining honest that configuration-driven migration policy, progress tracking, and host-level proxy behavior are later work

Delivered:

• Cephalon.Abstractions now ships IStranglerFigRouteContributor, IStranglerFigRouteRegistry, IStranglerFigRuntimeCatalog, IStranglerFigRouter, StranglerFigRequest, StranglerFigRouteDescriptor, StranglerFigRouteResolution, and StranglerFigTarget
• Cephalon.Engine now composes strangler-fig routes from both EngineBuilder.AddStranglerFigRoute(...) and module contributors, automatically keeps the strangler-fig pattern visible in AppProfile.Patterns when routes exist, and projects the route set into snapshot.StranglerFigRoutes
• Cephalon.AspNetCore now exposes /engine/strangler-fig, /engine/strangler-fig/{routeId}, and /engine/strangler-fig/resolve as direct operator routes over the shared runtime contracts
• targeted composition, hosting, and package-surface coverage now prove route collection, longest-prefix plus fallback request resolution, runtime snapshot projection, and the new abstraction-layer public surface
• architecture recommendations, component docs, roadmap, backlog, and project memory now describe the shipped contract-first strangler-fig baseline truthfully while keeping progress tracking, Engine:Migration configuration, and host-specific cutover behavior explicitly planned

ENG-101 Phase 12 strangler-fig migration policy and progress baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-096, operators could see the authored strangler-fig route catalog and probe request resolution, but the runtime still lacked one engine-owned answer for requested-versus-effective migration target policy and route-level progress
• teams adopting Cephalon incrementally need migration policy to stay configuration-driven so target cutover defaults and route-specific overrides do not force project-local host code rewrites
• the strangler-fig operator story was still incomplete because /engine/snapshot and ASP.NET Core hosts could not distinguish authored preference from configuration-driven target selection or report route-level migration progress truthfully

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic strangler-fig migration-policy runtime catalog plus a typed runtime descriptor for effective target selection and progress answers
• Cephalon.Engine binds Engine:Migration:StranglerFig, validates route-targeting truthfully, applies default plus per-route overlays deterministically, and projects the effective answer into /engine/snapshot
• ASP.NET Core hosts expose direct operator routes for the effective strangler-fig migration-policy catalog without changing the existing authored route-catalog surface
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the policy/progress scope while remaining honest that host-level cutover or proxy behavior is still later work

Delivered:

• Cephalon.Abstractions now ships IStranglerFigMigrationRuntimeCatalog plus StranglerFigMigrationRuntimeDescriptor so hosts, tooling, and companion packs can read effective requested-versus-selected target answers and route-level migration progress without referencing Cephalon.Engine concrete types
• Cephalon.Engine now binds Engine:Migration:StranglerFig through MigrationSettings, StranglerFigMigrationSettings, and StranglerFigRoutePolicySettings, validates unknown route-policy ids fail fast, and applies default plus per-route target/progress overlays deterministically in StranglerFigRuntimeCatalogSnapshot
• /engine/snapshot now also projects StranglerFigRoutePolicies, while request resolution metadata now reports requested target, target source, selection mode, progress state, progress percent, and optional route notes truthfully for the matched route
• Cephalon.AspNetCore now exposes /engine/strangler-fig/runtime and /engine/strangler-fig/runtime/{routeId} as the direct operator surface for effective strangler-fig migration policy answers while preserving /engine/strangler-fig as the authored route-catalog surface
• targeted composition, hosting, and package-surface coverage now prove default plus per-route overlay behavior, snapshot/runtime-route projection, fail-fast validation for unknown route policies, and the new abstraction-layer public surface through composition tests 4/4, hosting tests 1/1, and package-surface tests 153/153
• architecture recommendations, component docs, roadmap, backlog, and project memory now describe the shipped policy/progress baseline truthfully while keeping host-level cutover and proxy behavior explicitly planned

ENG-102 Phase 12 ASP.NET Core strangler-fig cutover runtime

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-101, Cephalon could explain authored route ownership plus effective target-selection and migration progress, but ASP.NET Core still could not execute the selected cutover target without project-local middleware or reverse-proxy glue
• teams migrating onto Cephalon need host cutover to stay derived from the same engine-owned migration truth so they can change ownership gradually without rewriting project endpoint code
• the operator story was still incomplete because ASP.NET Core could not yet answer which routes would rewrite locally, redirect or proxy to absolute endpoints, or fail because the selected target was not executable by the host

Acceptance:

• ASP.NET Core hosts expose a first host-level cutover runtime derived from IStranglerFigMigrationRuntimeCatalog instead of inventing a second cutover registry
• Engine:Migration:StranglerFig:AspNetCore controls whether cutover is active and whether absolute HTTP or HTTPS targets redirect or proxy without changing the underlying migration-policy truth
• ASP.NET Core hosts expose direct operator routes for the cutover view and one request-shaped cutover-resolution probe
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped cutover scope while remaining honest that provider-specific ingress or edge automation is still later work

Delivered:

• Cephalon.AspNetCore now ships an internal cutover catalog plus middleware derived from IStranglerFigMigrationRuntimeCatalog, so the host can resolve effective route ownership once and then apply the matching local rewrite, absolute redirect, absolute proxy, or truthful unsupported-target failure path
• Engine:Migration:StranglerFig:AspNetCore now binds typed host options for enabling cutover and selecting absolute-endpoint redirect versus proxy behavior without replacing Engine:Migration:StranglerFig as the runtime source of truth
• ASP.NET Core now exposes /engine/strangler-fig/cutover, /engine/strangler-fig/cutover/{routeId}, and /engine/strangler-fig/cutover/resolve as the direct operator surface for host-level cutover handling answers
• rooted local selected endpoints now rewrite in-process before endpoint execution, absolute HTTP or HTTPS selected endpoints can redirect or proxy through a dedicated host-owned HttpClient, and unsupported selected endpoints now fail truthfully with 502
• targeted hosting coverage now proves local rewrite, absolute redirect, absolute proxy, and unsupported-target failure behavior while existing composition plus package-surface coverage proves the shared migration runtime truth remains intact through hosting tests 5/5, composition tests 4/4, and package-surface tests 153/153
• architecture recommendations, component docs, roadmap, backlog, and project memory now describe the shipped cutover baseline truthfully while keeping provider-specific ingress or edge automation explicitly planned

ENG-120 Phase 13 cell-boundary contract baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• phase 13 called for cell-based architecture, but Cephalon still had no host-agnostic contract for which module owned a cell boundary, what blast radius that boundary represented, or how operators could inspect the active cell topology without a host-only registry
• future routing, health-isolation, and edge-aware traffic automation need one deterministic runtime truth for cells before any companion-pack or host-specific follow-through can be layered on top
• the app-model story was also incomplete because a built-in cell-based-architecture profile existed only in planning docs and could not yet become an observable runtime answer

Acceptance:

• Cephalon.Abstractions exposes host-agnostic contribution and read contracts for explicit module-owned cell boundaries
• Cephalon.Engine composes host-added and module-contributed cell boundaries into one runtime catalog, projects the same answer into snapshot.CellBoundaries, and surfaces the same topology through the technology runtime catalog without inventing a second registry
• active cell boundaries auto-select the built-in cell-based-architecture profile so operator tooling can read one truthful technology answer without extra host ceremony
• ASP.NET Core hosts expose direct operator routes for the merged cell-boundary catalog and its cell/module drill-down answers
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped baseline while remaining honest that deeper routing, health-isolation, data mesh, and CDC follow-through are still later work

Delivered:

• Cephalon.Abstractions now ships CellBoundaryDescriptor, ICellBoundaryContributor, ICellBoundaryRegistry, and ICellBoundaryCatalog so modules, hosts, and tooling can talk about explicit module-owned cell boundaries without referencing Cephalon.Engine concrete types
• Cephalon.Engine now supports engine.AddCellBoundary(...) plus module-owned ICellBoundaryContributor inputs, validates referenced modules deterministically, composes one ICellBoundaryCatalog, projects snapshot.CellBoundaries, and publishes the same answer through the cell-boundaries technology runtime surface
• active cell boundaries now auto-select the built-in cell-based-architecture profile so /engine/technologies, /engine/technology-catalog, and /engine/technology-surfaces/cell-based-architecture stay aligned with the live topology
• Cephalon.AspNetCore now exposes /engine/cells, /engine/cells/{cellId}, and /engine/cells/modules/{moduleId} as the direct operator routes for the merged cell-boundary catalog
• targeted coverage now proves catalog composition, invalid-module rejection, runtime-snapshot projection, ASP.NET Core route publication, and public package-surface alignment through composition tests 2/2, hosting tests 1/1, and tooling tests 166/166

ENG-123 Phase 13 configuration-driven cell traffic automation baseline

Status: done Estimate: 5 Completed: April 20, 2026

Why:

• ENG-120, ENG-121, and ENG-122 established who owns each cell boundary, how cells route to one another, and how dependency failures isolate, but Cephalon still had no engine-owned answer for effective traffic automation policy without inventing a host-only traffic manager or service-mesh registry
• phase 13 still needed one additive overlay that kept route and module ownership authoritative while letting projects express default or per-route automation posture through configuration
• the operator story was still incomplete because /engine/snapshot and /engine/technology-surfaces/cell-based-architecture could not yet show effective automation, trigger, action, or materialization posture over the shipped route plus health-isolation graph

Acceptance:

• Cephalon.Abstractions exposes host-agnostic read contracts for effective cell traffic-automation answers
• Cephalon.Engine binds Engine:Cells:TrafficAutomation into one runtime catalog, validates configured route overlays against active governed routes, projects the same answer into snapshot.CellTrafficAutomations, and surfaces the same posture through the technology runtime catalog without replacing route authorship truth
• active traffic-automation answers keep the built-in cell-based-architecture profile truthful so operator tooling can read topology, routing, health-isolation, and automation posture from one runtime answer without extra host ceremony
• ASP.NET Core hosts expose direct operator routes for the merged cell traffic-automation catalog and its automation/module/route/source-cell/target-cell/health-isolation drill-down answers
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped baseline while remaining honest that provider-specific or edge-aware traffic automation, data mesh, and CDC are still later work

Delivered:

• Cephalon.Abstractions now ships CellTrafficAutomationRuntimeDescriptor and ICellTrafficAutomationRuntimeCatalog so hosts, modules, and tooling can read effective automation posture without referencing Cephalon.Engine concrete types
• Cephalon.Engine now binds Engine:Cells:TrafficAutomation through CellSettings, CellTrafficAutomationSettings, and CellTrafficAutomationRouteSettings, validates configured route ids at build time, derives effective automation answers from the active route plus health-isolation graph through one ICellTrafficAutomationRuntimeCatalog, projects snapshot.CellTrafficAutomations, and publishes the same answer through the cell-traffic-automations technology runtime surface
• Cephalon.AspNetCore now exposes /engine/cell-traffic-automations, /engine/cell-traffic-automations/{automationId}, /engine/cell-traffic-automations/modules/{moduleId}, /engine/cell-traffic-automations/routes/{routeId}, /engine/cell-traffic-automations/source-cells/{cellId}, /engine/cell-traffic-automations/target-cells/{cellId}, and /engine/cell-traffic-automations/health-isolations/{healthIsolationId} as the direct operator routes for the merged traffic-automation catalog
• targeted coverage now proves catalog composition, invalid-route rejection, technology-surface projection, runtime-snapshot projection, ASP.NET Core route publication, and public package-surface alignment through composition tests 2/2, hosting tests 1/1, and tooling tests 169/169

ENG-130 Phase 13 CDC execution runtime catalog baseline

Status: done Estimate: 5 Completed: April 20, 2026

Why:

• ENG-128 and ENG-129 made the shared CDC pump execute and acknowledge truthfully, but operators still had no engine-first answer for which execution runtime owned which captures or what topology that runtime represented
• future provider-native or out-of-process CDC runners needed one additive execution-runtime contract so alternate topologies can join the same operator story without replacing the per-capture descriptor or runtime-state truth
• /engine/snapshot could already show per-capture posture and shared execution-story steps, but it still could not answer one aggregate runner question directly: what execution runtime is active, which captures does it own, and what is its latest combined posture

Acceptance:

• Cephalon.Abstractions exposes additive CDC execution-runtime contracts that keep ownership, topology, linked capture ids, and aggregate runtime summary host-agnostic
• Cephalon.Data contributes the shared data-cdc-capture-pump execution runtime and derives its aggregate operator summary from the shared CDC runtime-state catalog without inventing a second runtime registry
• Cephalon.Engine plus Cephalon.AspNetCore project the same execution-runtime truth through snapshot.CdcCaptureExecutionRuntimes and /engine/cdc-capture-runtimes* while keeping /engine/cdc-captures* and /engine/cdc-captures/runtime* authoritative for per-capture detail
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while remaining explicit that provider-native or out-of-process CDC execution topologies are still later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeDescriptor, CdcCaptureExecutionRuntimeSummary, and ICdcCaptureExecutionRuntimeCatalog, so hosts and packs can publish one host-agnostic execution-runtime answer with stable ids, ownership metadata, linked capture ids, and aggregate operator posture
• Cephalon.Data now ships ICdcCaptureExecutionRuntimeContributor, ICdcCaptureExecutionRuntimeRegistry, CdcCaptureExecutionRuntimeCatalog, and SharedCdcCaptureExecutionRuntimeContributor, so the shared data-cdc-capture-pump runtime publishes executionOwnership = host-managed, executionTopology = shared-in-process-polling, acknowledgementMode = post-stage-provider, and 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 plus /engine/cdc-capture-runtimes/{executionRuntimeId} so operators can query execution topology without replacing the existing per-capture CDC surfaces
• targeted coverage now proves shared execution-runtime catalog composition, derived summary projection, ASP.NET Core route publication, snapshot projection, and package-surface alignment through composition tests 9/9, hosting tests 1/1, and tooling tests 3/3

ENG-131 Phase 13 CDC execution ownership binding baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-130 made CDC execution runtimes queryable, but the inverse capture-to-runtime binding still was not a first-class engine answer on /engine/cdc-captures* or /engine/cdc-captures/runtime*
• the shared Cephalon.Data pump still iterated every active capture with a matching ICdcCapture implementation, so future provider-native or externally managed runners would have risked duplicate execution without deterministic ownership filtering
• later provider-native or out-of-process CDC topologies needed one additive binding model that could keep authored, requested, and effective ownership visible on the per-capture surfaces instead of inventing a second ownership registry beside the execution-runtime catalog

Acceptance:

• Cephalon.Abstractions exposes additive, host-agnostic capture-side execution-binding contracts so descriptor and runtime-state surfaces can both report authored, requested, and effective execution-runtime ids plus the resolved ownership mode
• Cephalon.Data resolves CDC execution ownership deterministically from authored capture intent plus active runtime claims, rejects ambiguous competing claims, and only lets the shared data-cdc-capture-pump execute captures whose effective owner resolves to that runtime
• Cephalon.Engine plus Cephalon.AspNetCore project the same ownership truth through /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, inverse execution-runtime drill-down routes, and snapshot without inventing a second public ownership registry
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while remaining explicit that provider-native and out-of-process CDC execution topologies are still later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionBindingDescriptor, and both CdcCaptureDescriptor plus CdcCaptureRuntimeState now carry ExecutionBinding so authored/requested/effective execution-runtime ids, resolved ownership mode, and selection reason stay on the per-capture truth
• Cephalon.Data now ships CdcCaptureExecutionBoundCatalog plus CdcCaptureExecutionRuntimeDescriptorCatalog, resolves deterministic runtime claims over the active capture set, rejects ambiguous competing claims, derives runtime-side cdcCaptureIds back out of the resolved capture binding, and keeps the shared pump scoped to captures whose effective owner is data-cdc-capture-pump
• Cephalon.AspNetCore now exposes /engine/cdc-captures/execution-runtimes/{executionRuntimeId} plus /engine/cdc-captures/runtime/execution-runtimes/{executionRuntimeId}, while snapshot.CdcCaptures, snapshot.CdcCaptureStates, and snapshot.CdcCaptureExecutionRuntimes all stay aligned with the same resolved ownership truth
• targeted coverage now proves unbound/default-shared/requested/runtime-claim ownership resolution, ambiguous-claim rejection, shared-pump filtering, ASP.NET Core inverse drill-down route publication, JSON serialization compatibility, and package-surface alignment through composition tests 12/12, hosting tests 1/1, and tooling tests 171/171

ENG-132 Phase 13 CDC external execution-runtime declaration baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-130 and ENG-131 made CDC execution topology and capture ownership queryable, but the engine still had no first-class host/config declaration path for external-managed, provider-native, or edge-owned runtimes that should appear in the same operator catalog
• the execution-runtime payload still leaned on metadata for several ownership/topology details, which made HTTP/operator consumers infer too much instead of reading one stable contract
• inverse capture/runtime drill-down routes still filtered ad hoc in some layers, so later alternate execution topologies risked runtime-truth drift if different surfaces recomputed ownership differently

Acceptance:

• Cephalon.Abstractions promotes stable first-class execution-runtime and execution-binding fields for ownership/topology semantics, and shared CDC catalogs can answer inverse execution-runtime lookups directly
• Cephalon.Data lets hosts declare additive CDC execution runtimes through DataRuntimeOptions without replacing per-capture ExecutionBinding truth or letting the shared pump execute externally owned captures
• Cephalon.Engine plus Cephalon.AspNetCore keep /engine/cdc-capture-runtimes*, /engine/cdc-captures*, /engine/cdc-captures/runtime*, and snapshot aligned on one ownership/runtime story for shared and externally declared runtimes alike
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while remaining explicit that concrete provider-native capture implementations and broader out-of-process execution automation are still later work

Delivered:

• Cephalon.Abstractions now gives CdcCaptureExecutionRuntimeDescriptor first-class executionOwnership, executionTopology, acknowledgementMode, hostedExecutionId, and executionGraphId fields, gives CdcCaptureExecutionBindingDescriptor first-class executionTopology, and extends ICdcCaptureCatalog plus ICdcCaptureRuntimeStateCatalog with shared inverse GetByExecutionRuntimeId(...) lookups
• Cephalon.Data now ships CdcCaptureExecutionRuntimeOptions, DataRuntimeOptions.CdcExecutionRuntimes, and ConfiguredCdcCaptureExecutionRuntimeContributor, so hosts can declare external-managed, provider-native, or other additive execution runtimes on the same runtime catalog without falsely claiming they are Cephalon-hosted executions
• the shared CDC runtime catalog now derives linked capture ids and aggregate runtime state from the same bound capture/runtime-state lookups used by the inverse ASP.NET Core routes, while the shared data-cdc-capture-pump skips captures effectively owned by configured external runtimes
• targeted coverage now proves configured provider-native runtime declaration, inverse catalog lookups, shared-pump exclusion for externally owned captures, ASP.NET Core route publication, JSON serialization compatibility, and package-surface alignment through composition tests 14/14, hosting tests 2/2, tooling tests 172/172, and the reference docs publish script

ENG-133 Phase 13 first provider-native CDC runner PoC

Status: done Estimate: 8 Completed: April 21, 2026

Why:

• ENG-132 allowed provider-native runtimes to be declared, but no shipped companion pack actually executed one yet, so the shared ownership/topology contract still was not proven against a real provider loop
• MongoDB change streams were the lowest-friction first provider-native path: they could prove durable checkpointing, outbox staging, and live runtime reporting without overfitting the shared CDC contract to relational WAL semantics
• provider packs also needed a way to contribute capture descriptors on behalf of another module without rewriting authored sourceModuleId, otherwise provider-native execution would blur module ownership at the catalog boundary

Acceptance:

• Cephalon.Data.MongoDB contributes provider-native change-stream capture descriptors, execution graph, hosted execution, and execution-runtime answers on the same /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces
• the provider-native runner stages outbox messages, persists resume-token checkpoints only after stage success, and reports live freshness/lag/publication/checkpoint/failure posture through the shared CDC runtime-state catalog
• capture descriptors preserve authored module ownership while keeping provider-pack contribution explicit, and the shared data-cdc-capture-pump continues to skip captures effectively owned by the MongoDB runtime
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while external or out-of-process CDC reporting remains later work

Delivered:

• Cephalon.Data.MongoDB now ships MongoDbChangeStreamCaptureOptions, MongoDbChangeStreamCaptureHostedService, MongoDbChangeStreamExecutionRuntimeContributor, MongoDbChangeStreamCheckpointEntry, and MongoDbDataRuntimeIds, so hosts can declare collection-scoped MongoDB change-stream captures, the pack publishes capability data.cdc.mongodb, and the runtime now exposes mongodb-change-stream-capture-flow plus mongodb-change-stream-capture-pump on the shared execution/runtime surfaces
• the provider-native runner now watches configured collections, serializes raw change documents as relaxed Extended JSON, stages deterministic outbox messages, persists durable resume-token checkpoints only after stage success, and reports provider-native acknowledgement plus checkpoint/failure metadata through the shared ICdcCaptureRuntimeReporter catalog path
• CdcCaptureRegistryAdapter now preserves authored sourceModuleId when a provider pack contributes a capture on behalf of another module and surfaces metadata.contributorModuleId separately so module ownership stays truthful without blocking provider-native execution
• targeted coverage now proves MongoDB replica-set bootstrap, provider-native capture staging/checkpointing, inverse execution-runtime routes, snapshot projection, shared-pump exclusion, and public package-surface alignment through composition tests 15/15, hosting tests 3/3, tooling tests 174/174, and the reference docs publish script

ENG-134 Phase 13 external CDC runtime live-reporting baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-132 let hosts declare external execution runtimes and ENG-133 proved one provider-native in-process runner, but out-of-process CDC runners still had no additive way to publish live runtime truth back into the shared operator surfaces
• operators needed one report-ingest seam that refreshed the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot answers without creating a second external-monitor registry beside the descriptor-backed runtime-state catalog
• because this new route mutates operator-facing state, the baseline needed to stay opt-in and validate effective capture ownership so an unrelated runtime could not overwrite another runtime’s posture

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic observation contract plus execution-runtime report sink so adapters or hosts can accept out-of-process CDC runtime reports without referencing Cephalon.Data concrete types
• Cephalon.Data adds an opt-in report sink on top of the shared runtime-state catalog, validates that every reported capture is effectively owned by the requested execution runtime, and refreshes the existing execution-runtime summaries without inventing a second registry
• ASP.NET Core maps one additive ingest route that is available only when the opt-in sink is active, returns the refreshed execution-runtime descriptor, and leaves /engine/cdc-captures* plus /engine/cdc-captures/runtime* as the canonical capture-first truth
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while richer external pull/reconciliation or edge-aware topologies remain later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureRuntimeObservation plus ICdcCaptureExecutionRuntimeReportSink, so host adapters and external-report bridges can describe capture observations through a host-agnostic contract keyed by executionRuntimeId and cdcCaptureId
• Cephalon.Data now adds DataRuntimeOptions.EnableExternalCdcRuntimeReporting, conditionally registers the shared CdcCaptureRuntimeStateCatalog as the execution-runtime report sink, validates effective execution ownership per capture, and stamps metadata.cdcCaptureExecutionRuntimeId while refreshing the same shared runtime-state catalog and derived execution-runtime summaries
• Cephalon.AspNetCore now maps POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports only when the opt-in sink is active, rejects mismatched ownership with 400, returns the refreshed execution-runtime descriptor on success, and keeps the existing /engine/cdc-captures/runtime* plus /engine/cdc-capture-runtimes* surfaces as the canonical read model
• targeted coverage now proves sink registration and ownership validation, opt-in route absence when disabled, successful report ingestion plus snapshot/runtime refresh when enabled, and public package-surface alignment through composition tests 16/16, hosting tests 3/3, tooling tests 175/175, and the reference docs publish script

ENG-135 Phase 13 provider and edge-aware cell traffic automation baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-123 shipped one configuration-driven traffic-automation catalog over routes plus health isolations, but provider handoff and edge targeting still only lived in free-form metadata or future-planning notes instead of one typed runtime contract
• operators could not filter the shared automation catalog by provider or edge node, which made it harder to correlate cell posture with service-mesh, gateway, or edge-runtime topology without rebuilding that answer outside the engine
• the next follow-through needed to stay additive: one shared runtime catalog should become provider-aware and edge-aware without taking a direct dependency on Cephalon.Edge or inventing a second traffic-manager registry

Acceptance:

• Cephalon.Abstractions extends the shared traffic-automation runtime descriptor plus catalog with first-class provider and edge targeting that stays host-agnostic
• Cephalon.Engine binds additive provider and edge defaults plus route overrides through Engine:Cells:TrafficAutomation, derives truthful materialization posture from those overlays, and keeps the same snapshot plus technology-surface truth without inventing another registry
• ASP.NET Core exposes provider and edge-node drill-down routes over that same shared traffic-automation catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while concrete provider-managed or edge-runtime materializers remain later work

Delivered:

• Cephalon.Abstractions now extends CellTrafficAutomationRuntimeDescriptor with first-class ProviderId plus EdgeNodeIds, and ICellTrafficAutomationRuntimeCatalog now adds GetByProvider(...) plus GetByEdgeNodeId(...) so hosts and tooling can query provider-aware and edge-aware automation posture without referencing engine internals
• Cephalon.Engine now extends CellTrafficAutomationSettings plus CellTrafficAutomationRouteSettings with additive DefaultProviderId, DefaultEdgeNodeIds, route ProviderId, and route EdgeNodeIds, derives provider-managed, edge-managed, or provider-and-edge-managed materialization posture when those overlays are present, and rejects explicit edge-node targeting unless edge-native-delivery is active
• Cephalon.AspNetCore now maps /engine/cell-traffic-automations/providers/{providerId} plus /engine/cell-traffic-automations/edge-nodes/{edgeNodeId}, while the existing cell-traffic-automations technology surface now carries the same typed provider and edge targeting metadata instead of relying on free-form notes alone
• targeted coverage now proves derived provider-and-edge materialization posture, provider and edge-node drill-down lookups, edge-technology validation, ASP.NET Core route publication, JSON serialization compatibility, and public package-surface alignment through composition tests 3/3, hosting tests 1/1, tooling tests 1/1, and the reference docs publish script

ENG-138 Phase 13 richer multi-provider cell traffic reconciliation baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-136 and ENG-137 proved provider-managed and edge-runtime materialization on the shared catalog, but provider materializers still had to be unique per providerId, edge materializers still failed whenever more than one candidate matched, and provider-and-edge-managed routes still had no one overall materialization answer
• future provider-specific control-plane or edge companion packs needed a deterministic way to coexist with generic fallback materializers on the same catalog instead of forcing one global implementation or inventing a second reconciliation registry
• operators still needed one requested-versus-selected-versus-observed answer on the shared /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface so partial provider-versus-edge divergence stayed visible without manual metadata parsing

Acceptance:

• Cephalon.Abstractions extends the shared provider and edge materializer contracts with deterministic selection inputs while keeping control-plane and edge-runtime implementation details host-agnostic, and CellTrafficAutomationRuntimeDescriptor carries one overall materialization posture in addition to the existing per-provider and per-edge fields
• Cephalon.Engine resolves provider and edge materializers through highest-priority match selection, fails only on ambiguous same-priority ties, and publishes requested, selected, and observed truth plus selection rationale back onto the same shared automation catalog without inventing a second registry
• ASP.NET Core, the technology surface, and the runtime snapshot keep surfacing the same /engine/cell-traffic-automations* payload family while exposing the richer reconciliation truth there instead of adding a new control-plane-only API family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while additional provider-specific materializers remain later work

Delivered:

• Cephalon.Abstractions now ships Priority plus CanMaterialize(...) on ICellTrafficAutomationProviderMaterializer, Priority on ICellTrafficAutomationEdgeMaterializer, the new shared partial materialization state, and derived MaterializationState, MaterializationObservedAtUtc, plus MaterializationError on CellTrafficAutomationRuntimeDescriptor
• Cephalon.Engine now selects the highest-priority matching provider or edge materializer, rejects only same-priority ambiguous matches, derives one overall materialization answer over provider-plus-edge posture, and publishes additive providerSelection.*, edgeSelection.*, and materialization.* runtime metadata on the same shared automation catalog plus technology surface
• targeted coverage now proves deterministic highest-priority selection, same-priority ambiguity failures, composite route-level materialization truth, ASP.NET Core publication of the enriched payloads, and public package-surface alignment through composition tests 7/7, hosting tests 1/1, tooling tests 175/175, and the reference docs publish script

ENG-139 Phase 13 Kubernetes Gateway API control-plane materializer PoC

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-136 through ENG-138 proved shared provider-materializer selection and reconciliation, but the runtime still lacked one concrete provider-specific control-plane pack that exercised those contracts against a recognizable gateway family
• cell traffic automation needed a first truthful provider-specific follow-through that could project real control-plane intent without moving Kubernetes or gateway assumptions into Cephalon.Engine
• operators still needed the provider-specific answer to stay additive over the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-based-architecture technology surfaces instead of spawning a second traffic registry

Acceptance:

• a new companion pack keeps Kubernetes Gateway API projection outside the engine core while using the shared ICellTrafficAutomationProviderMaterializer contract
• selected provider-managed routes can project deterministic Gateway API intent, selected materializer ownership, and provider-specific metadata back into the shared runtime truth without inventing a second control-plane registry
• the provider-specific pack contributes its own technology surface so operators can inspect projected control-plane intent directly while the canonical automation truth still lives on the shared cell catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while live cluster reconciliation remains later work

Delivered:

• Cephalon.Edge.KubernetesGateway now ships KubernetesGatewayTrafficMaterializerOptions, KubernetesGatewayTrafficRouteOptions, AddKubernetesGatewayTrafficMaterializer(...), and a provider-specific ICellTrafficAutomationProviderMaterializer for providerId = "kubernetes-gateway"
• the new pack now projects deterministic Kubernetes Gateway API intent for selected routes, including providerRouteId, Gateway resource identity, parent references, backend references, hostname lists, controller identity, and truthful statusSource = configured-intent plus unknown condition placeholders because this slice stays at projected intent rather than live cluster observation
• the shared runtime story stays singular: /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and /engine/technology-surfaces/cell-based-architecture now surface the same selected provider materializer plus provider metadata, while the new kubernetes-gateway-traffic-materializations surface gives operators one provider-facing drill-down over those same routes without a second registry
• targeted coverage now proves Kubernetes Gateway materializer selection over lower-priority fallbacks, unavailable posture for unmapped routes, ASP.NET Core publication of the provider-specific surface, and public package-surface alignment through composition tests 2/2, hosting tests 1/1, tooling tests 176/176, and the reference docs publish script

ENG-140 Phase 13 Kubernetes Gateway live reconciliation baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-139 proved deterministic Kubernetes Gateway API projected intent, but the pack still had no truthful way to read live Gateway plus HTTPRoute status back into the shared automation catalog
• cell traffic automation still needed one host-agnostic seam for provider-owned live observations so future control-plane or edge packs could refresh runtime truth without inventing a second traffic-materialization registry
• operators needed the provider-specific route view, shared /engine/cell-traffic-automations* payloads, and snapshot.CellTrafficAutomations to agree on observed condition, drift, and freshness posture instead of leaving live reconciliation trapped inside a provider-local loop

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic cell traffic automation materialization report sink that lets provider or edge observers merge live posture back into the active shared runtime catalog
• Cephalon.Engine keeps the shared CellTrafficAutomationRuntimeCatalogSnapshot as canonical truth while allowing selected provider or edge materializers to overlay live observations without inventing a second registry
• Cephalon.Edge.KubernetesGateway adds an opt-in observe-only mode that reads live Gateway API status, publishes Accepted/ResolvedRefs/Programmed, drift, and freshness metadata back onto the same shared runtime payloads, and leaves projected-intent mode as the default additive baseline
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while live apply-and-reconcile loops remain later work

Delivered:

• Cephalon.Abstractions now ships ICellTrafficAutomationMaterializationReportSink, so provider and edge observers can report live materialization posture back into the shared runtime catalog through one host-agnostic contract
• Cephalon.Engine now registers that sink over the same CellTrafficAutomationRuntimeCatalogSnapshot, and the provider plus edge hosted services now depend on the public runtime-catalog and report-sink abstractions instead of a concrete engine-only snapshot type
• Cephalon.Edge.KubernetesGateway now ships KubernetesGatewayTrafficObservationModes plus KubernetesGatewayTrafficObservationOptions, adds opt-in observe-only mode to KubernetesGatewayTrafficMaterializerOptions, can build or accept a Kubernetes client, and now polls live Gateway plus HTTPRoute status so provider-managed routes publish observed condition, drift, and freshness metadata through the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations surfaces
• targeted coverage now proves observe-only projected startup truth plus recurring polling refresh through composition tests 4/4, ASP.NET Core publication of the live observation surface through hosting tests 2/2, public package-surface alignment through tooling tests 176/176, and the reference docs publish script

ENG-141 Phase 13 Kubernetes Gateway apply-and-reconcile baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-140 proved projected intent plus live observation, but the provider-specific pack still had no truthful baseline for writing control-plane resources back into Kubernetes
• configured-intent answers still needed to stay honest: projected routes should remain pending until live control-plane evidence exists instead of reading as implicitly applied
• operators needed ownership-aware apply results and observed Gateway API status to stay on the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations surfaces instead of spawning a second provider-local apply registry

Acceptance:

• Cephalon.Edge.KubernetesGateway exposes a third apply-and-reconcile control-plane mode alongside configured-intent and observe-only
• configured-intent stays truthful by publishing projected metadata while keeping provider materialization state pending
• apply-and-reconcile writes only owned HTTPRoute resources, treats Gateway as a pre-provisioned dependency, blocks foreign-resource takeover through explicit ownership checks, and then merges observed Gateway API status back into the same shared runtime payloads
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader low-code generation and additional provider families remain later work

Delivered:

• KubernetesGatewayTrafficObservationModes now adds apply-and-reconcile, KubernetesGatewayTrafficAutomationMaterializer now keeps configured-intent answers at pending, and the recurring hosted reconciliation loop now covers both observe-only and apply-and-reconcile control-plane modes
• Cephalon.Edge.KubernetesGateway now introduces IKubernetesGatewayTrafficApplyService; the concrete observation source can now create or replace owned HTTPRoute resources, records httpRouteWriteAction, httpRouteAppliedGeneration, httpRouteAppliedResourceVersion, ownershipState, and gatewayWriteReason = preprovisioned-dependency, and then merges observed Gateway plus HTTPRoute status back into the same shared provider materialization answer
• the pack now stamps owned HTTPRoute resources with stable Cephalon ownership labels and annotations, blocks conflicting foreign resources with an explicit ownership-conflict posture, and keeps Gateway ownership outside the current baseline
• targeted coverage now proves truthful configured-intent posture, apply-and-reconcile startup behavior, recurring reconciliation refresh, ASP.NET Core publication of the new provider metadata, public package-surface alignment through composition tests 6/6, hosting tests 3/3, tooling tests 176/176, and the reference docs publish script

ENG-142 Phase 13 Traefik IngressRoute control-plane materializer baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-139 through ENG-141 proved the provider-materializer seam against Kubernetes Gateway API, but the architecture still needed a second control-plane family to prove the abstraction was not overfit to one provider’s resource model
• cell traffic automation still needed a sibling provider pack that could publish route match, middleware, backend service, and TLS intent back onto the same shared automation catalog without inventing a second provider-local registry
• operators needed the provider drill-down on /engine/cell-traffic-automations/providers/{providerId}, snapshot.CellTrafficAutomations, and technology-surfaces to stay truthful when a second provider family participates in selection

Acceptance:

• a new companion pack keeps Traefik IngressRoute projection outside the engine core while using the shared ICellTrafficAutomationProviderMaterializer contract
• selected provider-managed routes can project deterministic Traefik IngressRoute intent, selected materializer ownership, and provider-specific metadata back into the shared runtime truth without inventing a second control-plane registry
• the provider-specific pack contributes its own technology surface so operators can inspect projected control-plane intent directly while the canonical automation truth still lives on the shared cell catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while live Traefik reconciliation remains later work

Delivered:

• Cephalon.Edge.Traefik now ships TraefikTrafficMaterializerOptions, TraefikIngressRouteOptions, TraefikMiddlewareReferenceOptions, AddTraefikTrafficMaterializer(...), and a provider-specific ICellTrafficAutomationProviderMaterializer for providerId = "traefik"
• the new pack now projects deterministic Traefik IngressRoute intent for selected routes, including providerRouteId, route namespace and name, entry points, match rules, middleware references, backend service references, TLS posture, and truthful statusSource = configured-intent because this slice stays at projected intent rather than live control-plane observation
• the shared runtime story stays singular: /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and /engine/technology-surfaces/cell-based-architecture now surface the same selected provider materializer plus Traefik metadata, while the new traefik-ingressroute-traffic-materializations surface gives operators one provider-facing drill-down over those same routes without a second registry
• targeted coverage now proves Traefik materializer selection over lower-priority fallbacks, unavailable posture for unmapped routes, ASP.NET Core publication of the provider-specific surface, public package-surface alignment, and supported reference-doc coverage through composition tests 2/2, hosting tests 1/1, tooling tests 180/180, and the reference docs publish script

ENG-143 Phase 13 control-plane ownership lifecycle hardening baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-141 and ENG-142 proved provider-specific projected intent, live observation, and owned apply-and-reconcile paths, but the shared runtime still lacked one stable lifecycle vocabulary for requested ownership, dependency posture, drift posture, and lifecycle action across providers and edge materializers
• operators still had to infer requested versus owned versus ownership-conflict or dependency-missing posture from provider-local metadata instead of reading one normalized answer back off the shared /engine/cell-traffic-automations* plus snapshot.CellTrafficAutomations surfaces
• future provider packs still needed a shared lifecycle baseline so they could publish truthful ownership-transfer, orphan, prune, drift, or dependency posture without inventing provider-local taxonomies or a second control-plane registry

Acceptance:

• Cephalon.Abstractions exposes stable lifecycle constants for ownership, dependency, drift, and lifecycle-action posture on the shared cell traffic materialization seam
• Cephalon.Engine keeps the shared CellTrafficAutomationRuntimeCatalogSnapshot as canonical truth while seeding default requested posture, merging observed lifecycle metadata, and deriving normalized materialization.* lifecycle summaries on the same shared runtime payloads
• Cephalon.Edge, Cephalon.Edge.KubernetesGateway, and Cephalon.Edge.Traefik publish the same ownership/dependency/drift/lifecycle-action vocabulary back onto the existing shared automation catalog and provider-specific technology surfaces without inventing a second registry
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while deeper provider-native prune/delete and live ownership-transfer cleanup remain later work

Delivered:

• Cephalon.Abstractions now ships CellTrafficAutomationOwnershipStates, CellTrafficAutomationDependencyStates, CellTrafficAutomationDriftStates, and CellTrafficAutomationLifecycleActions so control-plane and edge packs can share one stable lifecycle vocabulary
• Cephalon.Engine now seeds default requested-versus-owned lifecycle posture onto selected provider and edge dimensions, merges observed lifecycle metadata back through the same ICellTrafficAutomationMaterializationReportSink, and derives normalized materialization.ownershipState, materialization.dependencyState, materialization.driftState, plus lifecycle-action breakdown metadata on the existing shared automation catalog
• Cephalon.Edge, Cephalon.Edge.KubernetesGateway, and Cephalon.Edge.Traefik now emit the same ownership/dependency/drift/lifecycle-action metadata so projected intent, live observation, owned apply-and-reconcile, and conflict or dependency-missing follow-through stay comparable across /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, kubernetes-gateway-traffic-materializations, and traefik-ingressroute-traffic-materializations
• targeted coverage now proves shared lifecycle summaries and provider-specific publication through composition tests 16/16, hosting tests 5/5, tooling tests 177/177, and the reference docs publish script

ENG-144 Phase 13 Traefik live observation baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-142 proved deterministic Traefik IngressRoute projected intent and ENG-143 normalized lifecycle truth, but the Traefik pack still had no truthful way to read live IngressRoute existence, ownership, dependency, or drift posture back into the shared automation catalog
• provider-specific control-plane follow-through still needed one additive observation path for a second provider family so the shared report-sink seam would not stay proven only against Kubernetes Gateway API
• operators needed /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations to agree on freshness, dependency-missing, ownership-conflict, and drift posture instead of leaving live Traefik evidence trapped in a provider-local loop

Acceptance:

• Cephalon.Edge.Traefik exposes first-class observation configuration alongside projected-intent options so hosts can opt into live Traefik observation without changing the shared engine-owned traffic catalog
• the shared ICellTrafficAutomationMaterializationReportSink remains canonical truth while selected Traefik materializers can overlay live observation back into the existing shared runtime payloads and provider-specific surface without inventing a second registry
• observe-only mode polls Traefik IngressRoute resources plus dependent Middleware, TLSOption, backend Service, and TLS Secret resources, publishing truthful route existence, dependency, ownership, drift, and freshness posture while leaving write ownership or apply-and-reconcile work for later follow-through
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while Traefik apply-and-reconcile and richer controller-native status semantics remain later work

Delivered:

• Cephalon.Edge.Traefik now ships TraefikTrafficObservationModes plus TraefikTrafficObservationOptions, binds them through TraefikTrafficMaterializerOptions.Observation, and registers an opt-in hosted observation loop only when observe-only mode is selected
• TraefikTrafficAutomationMaterializer now distinguishes truthful configured-intent versus observe-only runtime posture, while TraefikTrafficObservationSource now reads live IngressRoute, Middleware, TLSOption, Secret, and backend Service resources so selected routes can publish resourceState, ownershipState, dependencyState, driftState, observationFreshUntilUtc, and statusSource = traefik-ingressroute-observation back through the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations surfaces
• the shared automation story stays singular: Cephalon.Engine still owns reconciliation truth through the existing report sink and runtime catalog, while the Traefik pack only contributes provider-specific observation semantics and metadata instead of inventing a Traefik-local status registry
• targeted coverage now proves observe-only startup truth plus recurring polling refresh through composition tests 4/4, ASP.NET Core publication of the live Traefik observation surface through hosting tests 2/2, public package-surface alignment through tooling tests 177/177, and the reference docs publish script

ENG-145 Phase 13 Traefik apply-and-reconcile baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-144 proved live Traefik observation, but the provider-specific pack still had no truthful owned-write baseline for IngressRoute resources on the shared traffic catalog
• configured intent still needed to stay honest: projected routes should remain pending until live control-plane evidence exists instead of reading as implicitly applied
• operators needed ownership-aware write results and reconciled live Traefik posture to stay on /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations instead of spawning a second provider-local apply registry

Acceptance:

• Cephalon.Edge.Traefik exposes apply-and-reconcile alongside configured-intent and observe-only
• configured intent stays truthful by publishing projected metadata while keeping provider materialization state pending
• apply-and-reconcile creates or replaces only owned IngressRoute resources, treats Middleware, TLSOption, backend Service, and TLS Secret resources as pre-provisioned dependencies, and then merges observed Traefik posture back into the same shared runtime payloads
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while deeper lifecycle execution remains later work

Delivered:

• TraefikTrafficObservationModes now adds apply-and-reconcile, TraefikTrafficAutomationMaterializer now keeps configured-intent answers at pending, and the recurring hosted reconciliation loop now covers both observe-only and apply-and-reconcile control-plane modes
• Cephalon.Edge.Traefik now introduces ITraefikTrafficApplyService; the concrete observation source can now create or replace owned IngressRoute resources, records ingressRouteWriteAction, ingressRouteAppliedGeneration, ownershipState, and dependency posture, and then merges observed Traefik route state back into the same shared provider materialization answer
• the pack now stamps owned IngressRoute resources with stable Cephalon ownership labels and annotations, blocks conflicting foreign resources with an explicit ownership-conflict posture, and keeps dependent middleware, TLS options, secrets, and backend services outside the current write baseline
• targeted coverage now proves truthful configured-intent posture, apply-and-reconcile startup behavior, ASP.NET Core publication of the new provider metadata, public package-surface alignment through composition tests 6/6, hosting tests 3/3, tooling tests 177/177, and the reference docs publish script

ENG-146 Phase 13 provider-native lifecycle execution hardening baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-141 and ENG-145 proved owned apply-and-reconcile loops, but merged provider answers still collapsed the last write lifecycle back to observe, which hid whether the reconciler had created, replaced, or transferred ownership of a control-plane resource
• ownership evaluation was still too coarse: operators could not distinguish external unmanaged resources from stale or incomplete Cephalon ownership metadata on the same shared runtime surfaces
• later prune/delete, transfer cleanup, and additional provider packs needed one truthful baseline for conflict versus orphan versus transfer semantics without inventing a second lifecycle registry

Acceptance:

• merged provider answers preserve the last apply lifecycle action (create, replace, or transfer) after live observation reconciliation instead of downgrading every successful result to observe
• Cephalon.Edge.KubernetesGateway and Cephalon.Edge.Traefik classify external unmanaged resources and active foreign owners as explicit ownership conflicts, while stale or incomplete Cephalon ownership metadata becomes an orphaned transfer candidate
• the shared /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces publish the same ownership, lifecycle-action, and previous-owner truth without circular host coupling or a second control-plane registry
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader dependency-aware lifecycle cleanup remains later work beyond the first explicit cleanup-sweep baseline

Delivered:

• KubernetesGatewayTrafficObservationSource and TraefikTrafficObservationSource now resolve active owners lazily through ICellTrafficAutomationRuntimeCatalog, avoiding circular DI while still checking current automation ownership during apply and observe flows
• both provider packs now distinguish external-unmanaged-resource and active-foreign-owner conflicts from stale-owner or incomplete-current-owner orphan posture, and apply-and-reconcile now keeps previous-owner metadata when a stale Cephalon-owned route is adopted as a transfer candidate
• KubernetesGatewayTrafficAutomationMaterializer and TraefikTrafficAutomationMaterializer now preserve providerMaterialization.lifecycleAction from control-plane apply results after merging live observation, so shared and provider-specific surfaces keep truthful create, replace, or transfer answers instead of collapsing back to observe
• targeted coverage now proves external-resource conflict detection, orphaned transfer candidates, and preserved apply lifecycle truth through composition tests 16/16, hosting tests 6/6, tooling tests 177/177, and the reference docs publish script

ENG-147 Phase 13 provider-native cleanup sweep execution baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-146 closed truthful conflict, orphan, and transfer semantics, but provider-managed routes still had no first-class cleanup answer when a selected automation disappeared or ownership had already moved elsewhere
• operators still had to delete or prune stale provider resources manually, even though the same shared runtime surfaces already knew enough ownership truth to describe safe cleanup candidates
• the shared control-plane story still needed one additive cleanup baseline that could stay on /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces without inventing a second lifecycle or garbage-collection registry

Acceptance:

• Cephalon.Edge.KubernetesGateway and Cephalon.Edge.Traefik support opt-in cleanup sweeps only when apply-and-reconcile mode is active and EnableCleanupSweep is enabled explicitly
• cleanup sweeps distinguish stale transferred resources from orphaned Cephalon-owned resources, delete transferred routes with lifecycleAction = delete, and prune orphaned routes with lifecycleAction = prune
• cleanup sweep summaries stay additive through providerMaterialization.cleanup* and provider-specific technology surfaces so operators can inspect cleanup posture without losing the selected route’s primary materialization answer
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice

Delivered:

• KubernetesGatewayTrafficObservationOptions and TraefikTrafficObservationOptions now expose EnableCleanupSweep, while provider observation sources add namespace-scoped cleanup sweep execution for owned HTTPRoute or IngressRoute resources
• Cephalon.Edge.KubernetesGateway and Cephalon.Edge.Traefik now surface additive cleanup metadata such as cleanupState, cleanupObservedAtUtc, cleanupError, and per-sweep lifecycle summaries on the same shared automation and provider-specific technology surfaces
• hosted observation loops now run optional cleanup sweeps before refreshing per-automation observation answers so delete/prune posture stays visible on the same runtime story as live provider status
• targeted coverage now proves truthful cleanup publication through composition tests 22/22, hosting tests 8/8, tooling tests 177/177, and the reference docs publish script

ENG-148 Phase 13 SQL Server provider-native CDC runner baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• phase 13 already proved shared CDC execution ownership, external runtime declaration, MongoDB provider-native execution, and out-of-process runtime reporting, but it still lacked a relational provider-native runner on the same ownership and runtime-story model
• the shared /engine/cdc-* surfaces needed proof that authored/requested/effective execution binding, runtime summaries, freshness, lag, publication posture, and checkpoint truth were not overfit to document-change streams alone
• the engine roadmap still called out additional provider-specific capture implementations, and SQL Server CDC is the most natural relational follow-through for the current .NET adoption path

Acceptance:

• a new Cephalon.Data.SqlServer companion pack contributes provider-native SQL Server CDC captures, execution graph, hosted execution, and execution runtime without changing Cephalon.Engine or Cephalon.Abstractions
• configured SQL Server CDC captures stay on the shared /engine/cdc-captures*, /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces with truthful provider-native ownership and host-managed execution ownership
• the provider-native runner stages outbox publications, persists durable SQL Server checkpoint tokens only after stage success, and preserves authored SourceModuleId truth while surfacing provider-pack contribution metadata explicitly
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice

Delivered:

• Cephalon.Data.SqlServer now ships SqlServerDataOptions, SqlServerCdcCaptureOptions, and AddSqlServerData(...) as the public provider-native SQL Server CDC pack surface
• the pack now contributes sqlserver-cdc-capture-flow, sqlserver-cdc-capture-pump, and sqlserver-cdc-capture-pump execution-runtime truth through SqlServerDataModule, SqlServerCdcExecutionRuntimeContributor, and SqlServerCdcCaptureHostedService
• the provider-native transport now polls SQL Server CDC change tables, emits deterministic application/vnd.cephalon.sqlserver.cdc+json outbox messages, and persists durable startLsn|seqval|operation checkpoints through the Cephalon-managed checkpoint table
• targeted coverage now proves truthful relational provider-native CDC publication through composition tests 17/17, hosting tests 1/1, tooling tests 179/179, and the reference docs publish script

ENG-149 Phase 13 external CDC runtime reporting hardening baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-134 made external CDC runtime reporting possible and ENG-148 proved the shared CDC model across document and relational providers, but out-of-process runtime reporting still had no first-class answer for retry idempotency, ordering guarantees, or freshness expiry after a reporter stopped sending updates
• operators could see the latest reported posture on /engine/cdc-captures/runtime* and /engine/cdc-capture-runtimes*, but they still could not distinguish a still-fresh external report from one that had silently gone stale
• external or managed runners needed one stable report-id contract and one declared stale-window policy so retried or delayed submissions would not duplicate totals or overwrite newer runtime truth

Acceptance:

• Cephalon.Abstractions extends the shared CDC reporting contracts with stable report-id, observation-freshness, and execution-runtime reporting-policy fields without pushing HTTP-specific semantics into the core
• Cephalon.Data treats matching duplicate report ids as idempotent retries, rejects conflicting duplicates or configured out-of-order submissions, and derives report freshness expiry on the existing capture/runtime catalogs instead of a second watchdog registry
• Cephalon.AspNetCore keeps the same POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports ingress while refreshed route payloads and /engine/snapshot now expose report identity plus observation-freshness truth directly
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader external or edge-aware CDC topologies remain later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureRuntimeObservation.ReportId, CdcCaptureExecutionRuntimeDescriptor.ObservationStaleAfterSeconds, CdcCaptureExecutionRuntimeDescriptor.RejectOutOfOrderReports, CdcCaptureRuntimeState.LastReportId, CdcCaptureRuntimeState.ObservationFreshness, CdcCaptureExecutionRuntimeSummary.LastReportId, and CdcCaptureExecutionRuntimeSummary.ObservationFreshness, while CdcCaptureFreshnessStates now also includes mixed for aggregate runtime summaries
• Cephalon.Data now extends CdcCaptureExecutionRuntimeOptions with stale-window and ordering policy, keeps CdcCaptureExecutionReport plus CdcCaptureRuntimeStateCatalog report ingestion idempotent by reportId, rejects configured out-of-order observations, stamps cdcCaptureReportId plus observationFreshness* metadata, and expires external observation freshness from the same declared runtime policy without introducing a second monitor
• CdcCaptureExecutionRuntimeCatalog now carries aggregate LastReportId plus runtime-level ObservationFreshness derived from the existing per-capture runtime state, so /engine/cdc-capture-runtimes*, /engine/cdc-captures/runtime*, and snapshot stay on one operator truth even when reports arrive from outside the host process
• targeted coverage now proves idempotent retry handling, out-of-order rejection, stale-window expiry, ASP.NET Core route publication, and public package-surface alignment through composition tests 19/19, hosting tests 4/4, tooling tests 179/179, and the reference docs publish script

ENG-150 Phase 13 richer provider-native condition semantics baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-143 through ENG-147 established shared ownership, dependency, drift, lifecycle, and cleanup posture for provider-managed traffic automation, but provider and edge materializers still had no first-class typed condition contract for readiness, observation, or provider-specific dependency truth
• operators could inspect provider-local metadata such as gatewayAcceptedCondition or ingressRouteExists, but the shared /engine/cell-traffic-automations* and snapshot.CellTrafficAutomations surfaces still lacked one additive, typed condition vocabulary that worked across provider, edge, and aggregate materialization answers
• the shared traffic runtime needed one stable condition taxonomy plus one summary model so provider packs could publish detailed control-plane answers without inventing provider-local condition registries or forcing operators to reverse-engineer raw metadata keys

Acceptance:

• Cephalon.Abstractions extends the shared traffic-materialization contract with stable condition dimensions, categories, states, severities, and a typed CellTrafficAutomationMaterializationConditionDescriptor without pushing provider-specific control-plane semantics into Cephalon.Engine
• provider and edge materialization results can publish typed Conditions, CellTrafficAutomationRuntimeDescriptor carries merged MaterializationConditions, and the shared runtime derives additive materialization.*, providerMaterialization.*, and edgeMaterialization.* summaries such as condition counts, category/state breakdowns, and highest severity on the existing shared surfaces instead of a second registry
• Cephalon.Edge, Cephalon.Edge.KubernetesGateway, and Cephalon.Edge.Traefik publish stable readiness, ownership, dependency, lifecycle, and observation conditions that keep provider-specific detail while remaining queryable through the shared runtime descriptor, provider-specific technology surfaces, and /engine/snapshot
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader dependency-aware teardown and deeper external or edge-aware CDC execution topologies remain later work

Delivered:

• Cephalon.Abstractions now ships CellTrafficAutomationMaterializationConditionDescriptor, CellTrafficAutomationMaterializationConditionDimensions, CellTrafficAutomationMaterializationConditionCategories, CellTrafficAutomationMaterializationConditionStates, and CellTrafficAutomationMaterializationConditionSeverities, while CellTrafficAutomationMaterializationResult plus CellTrafficAutomationProviderMaterializationResult now carry typed Conditions and CellTrafficAutomationRuntimeDescriptor now carries merged MaterializationConditions
• Cephalon.Engine now preserves typed provider and edge conditions inside CellTrafficAutomationRuntimeCatalogSnapshot, derives additive materialization.*, providerMaterialization.*, and edgeMaterialization.* summaries such as conditionCount, conditionIds, conditionCategories, conditionStates, conditionSeverities, conditionBreakdown, and highestConditionSeverity, and seeds observation failure conditions when provider or edge materializers are missing or fail during hosted reconciliation
• Cephalon.Edge now publishes stable edge-side runtime-observable, ownership, dependencies, intent-alignment, and reconcile-action conditions; Cephalon.Edge.KubernetesGateway now publishes the same shared condition taxonomy plus provider-specific readiness conditions such as gateway-accepted, gateway-programmed, http-route-accepted, and http-route-resolved-refs; and Cephalon.Edge.Traefik now publishes the same shared taxonomy plus provider-specific conditions such as ingress-route-present, backend-service-present, tls-options-present, tls-secret-present, and middleware-present
• targeted coverage now proves merged provider plus edge condition projection, provider-specific condition publication on shared and provider-specific HTTP surfaces, public package-surface alignment, and generated reference-doc publishing through composition tests 30/30, hosting tests 9/9, tooling tests 179/179, and the reference docs publish script

ENG-151 Phase 13 broader dependency-aware teardown baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-147 shipped the first delete/prune cleanup sweeps for provider-owned primary routes and ENG-150 added typed lifecycle and condition truth, but cleanup metadata still flattened primary-versus-dependent resource answers and both provider packs still looked equivalent even though only one of them could reasonably clean up safe owned dependents
• operators could inspect cleanupState and cleanup.lifecycleActions, yet they still could not tell whether a provider remained intentionally route-only or had actually removed related provider-owned dependencies on the same pass
• phase 13 still needed one additive dependency-aware teardown baseline that stayed on the existing shared traffic runtime surfaces while letting each provider pack truthfully advertise how far its cleanup model currently goes

Acceptance:

• the shared providerMaterialization.cleanup* answer publishes an explicit cleanup strategy plus primary/dependency cleanup breakdowns on the existing /engine/cell-traffic-automations*, provider-specific technology surfaces, and snapshot.CellTrafficAutomations instead of a new teardown registry
• Cephalon.Edge.KubernetesGateway keeps cleanup explicitly route-only through cleanupStrategy = primary-only, while Cephalon.Edge.Traefik broadens cleanup to safe owned Middleware and TLSOption dependents when ownership truth and active projection state allow it
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while deeper external or edge-aware CDC execution topologies and broader provider-side teardown families remain later work

Delivered:

• Cephalon.Edge.KubernetesGateway now publishes additive cleanup metadata such as cleanupStrategy, primaryCandidateCount, removedPrimaryResourceCount, and zeroed dependency counts so operators can see that the current pack intentionally remains primary-only for owned HTTPRoute sweeps
• Cephalon.Edge.Traefik now broadens EnableCleanupSweep beyond primary IngressRoute resources by safely deleting stale transferred or orphaned Cephalon-managed Middleware and TLSOption dependents that are no longer referenced by active projections, while backend Service and TLS Secret dependencies remain observe-only
• shared cleanup summaries now expose aggregate plus primary/dependency breakdowns such as candidateCount, removedResourceCount, primaryCandidateCount, dependencyCandidateCount, dependencyKinds, and additive resource-id lists on the same shared and provider-specific surfaces without inventing a second lifecycle registry
• targeted coverage now proves the shipped cleanup-strategy metadata, route-only Kubernetes behavior, Traefik dependency cleanup disposition, shared HTTP surface publication, public package-surface alignment, and generated reference-doc publishing through composition tests 24/24, hosting tests 8/8, tooling tests 179/179, and the reference docs publish script

ENG-152 Phase 13 deeper external and edge-aware CDC execution topologies baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-149 hardened retry, ordering, and freshness-expiry truth for external CDC reporting, but the shared runtime story still could not answer which runner or edge agent most recently spoke for one execution runtime or keep one external reporter authoritative while several external workers targeted the same runtime
• edge-aware or externally coordinated CDC topologies needed additive reporter identity, lease, and edge provenance on the existing /engine/cdc-* plus snapshot surfaces instead of a second coordination or watchdog registry
• phase 13 still needed one deeper topology baseline that stayed descriptor-backed and host-agnostic while letting ASP.NET Core expose the same runtime policy and failure semantics to operators

Acceptance:

• CdcCaptureRuntimeObservation, CdcCaptureExecutionReport, CdcCaptureRuntimeState, and CdcCaptureExecutionRuntimeSummary surface first-class reporter and edge-node identity, while CdcCaptureExecutionRuntimeDescriptor can declare ReporterLeaseSeconds, RejectConflictingReporterIds, and EdgeNodeIds
• the shared external-reporting seam keeps retries, stale-window freshness, and out-of-order policy intact while also rejecting conflicting reporters during an active lease and rejecting reports from undeclared edge nodes on the same runtime-state catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while additional provider-native CDC implementations and broader provider-side teardown families remain later work

Delivered:

• Cephalon.Abstractions now promotes ReporterId plus EdgeNodeId on CdcCaptureRuntimeObservation, first-class reporter-lease and edge-node declaration fields on CdcCaptureExecutionRuntimeDescriptor, and first-class LastReporterId, ActiveReporterId, ReporterLeaseExpiresAtUtc, ObservedEdgeNodeIds, and LastEdgeNodeId on the shared execution-runtime summary plus runtime-state contracts
• Cephalon.Data now derives reporter-lease expiry from declared runtime policy, rejects conflicting reporters while an active lease still exists, rejects undeclared edge nodes for edge-aware runtimes, stamps additive reporter/edge metadata such as cdcCaptureReporterId, cdcCaptureReporterLeaseExpiresAtUtc, and cdcCaptureEdgeNodeId, and keeps the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot answers truthful without inventing a second topology coordinator
• targeted coverage now proves the deeper external and edge-aware runtime story through composition tests 21/21, hosting tests 5/5, tooling tests 179/179, and the reference docs publish script

ENG-153 Phase 13 PostgreSQL provider-native CDC runner baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-148 proved the shared CDC runtime story on a relational change-table source, but the engine still lacked a provider-native logical-replication streaming proof that used slot-backed durable progress instead of a Cephalon-managed checkpoint table
• phase 13 still needed one more provider-specific capture implementation to prove that the shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces fit publication/slot-based streaming without inventing a PostgreSQL-only registry or monitor
• PostgreSQL-specific publication ownership, slot lifecycle, pgoutput batching, and outbox-stage-first acknowledgement had to stay additive over the shipped capture/runtime-state/execution-runtime contracts rather than bypass them

Acceptance:

• Cephalon.Data.Postgres contributes provider-native PostgreSQL logical-replication captures through AddPostgresData(...), PostgresDataOptions, and PostgresLogicalReplicationCaptureOptions while keeping descriptor ownership, execution binding, runtime-state truth, execution-runtime summaries, and hosted execution on the existing shared surfaces
• the PostgreSQL runner validates publication/table ownership, optionally creates the logical replication slot, reads bounded committed pgoutput batches, stages linked outbox messages, and only confirms slot progress after outbox stage success while keeping durable checkpoint truth grounded in the slot itself
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while Postgres-specific publication/slot hardening and later provider-specific capture implementations remain later work

Delivered:

• Cephalon.Data.Postgres now ships PostgresDataOptions, PostgresLogicalReplicationCaptureOptions, PostgresDataModule, AddPostgresData(...), postgresql-logical-replication-capture-flow, postgresql-logical-replication-capture-pump, PostgresLogicalReplicationTransport, and slot-backed checkpoint tokens serialized as slotName|commitLsn|transactionEndLsn
• the provider-native runner now validates declared publication/table ownership, optionally creates the replication slot, reads one bounded committed pgoutput batch per iteration, stages deterministic outbox publications with content type application/vnd.cephalon.postgresql.logical-replication+json, and only confirms slot flush progress after stage success while keeping replicationCheckpointSource = slot-confirmed-flush-lsn on the shared runtime story
• targeted coverage now proves the provider-native PostgreSQL runtime story through composition tests 22/22, hosting tests 1/1, tooling tests 181/181, and the reference docs publish script

ENG-158 Phase 13 MySQL binlog provider-native CDC baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-157 hardened the shared external reporter story, but phase 13 still lacked a provider-native MySQL capture implementation on the same shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces already proven by MongoDB, SQL Server, and PostgreSQL
• the engine still needed one truthful binlog-based relational proof that kept durable file-plus-position checkpoints, provider-owned execution, and outbox-stage-first checkpoint commit on the existing runtime story instead of inventing a MySQL-specific monitor or registry
• MySQL-specific transport seams still had to stay additive over the shipped shared CDC descriptor, runtime-state, execution-runtime, execution-graph, hosted-execution, and runtime-story contracts instead of bypassing them with a provider-local operator surface

Acceptance:

• Cephalon.Data.MySql contributes provider-native MySQL binlog captures through AddMySqlData(...), MySqlDataOptions, and MySqlBinlogCaptureOptions while keeping descriptor ownership, execution binding, runtime-state truth, execution-runtime summaries, execution graphs, hosted executions, and runtime-story truth on the existing shared surfaces
• the MySQL runner resolves its starting position from a durable Cephalon-managed checkpoint row or a bounded configured initial position, reads one bounded binlog row-event batch per iteration, stages linked outbox publications, and only persists the next checkpoint after outbox stage success while keeping binlogFile, binlogPosition, binlogResumeMode, and checkpoint-store truth on the shared runtime story
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while MySQL-specific lifecycle and resume hardening plus broader external CDC follow-through remain later work

Delivered:

• Cephalon.Data.MySql now ships MySqlDataOptions, MySqlBinlogCaptureOptions, MySqlDataModule, AddMySqlData(...), mysql-binlog-capture-flow, mysql-binlog-capture-pump, MySqlBinlogTransport, and durable checkpoint tokens serialized as binlogFile|position
• the provider-native runner now resolves bounded starting position from the Cephalon-managed checkpoint table or from configured initial binlog posture, reads one bounded row-event batch per iteration, stages deterministic outbox publications with content type application/vnd.cephalon.mysql.binlog+json, and only persists the next durable checkpoint after stage success while keeping provider-native binlog checkpoint truth on the shared runtime story
• targeted coverage now proves the provider-native MySQL runtime story through composition tests 25/25, hosting tests 1/1, tooling tests 183/183, and the reference docs publish script

ENG-159 Phase 13 MySQL lifecycle and resume hardening follow-through

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-158 proved the provider-native MySQL binlog runner, but the shared CDC runtime story still needed truthful provider-native answers for retained-binlog lifecycle, restart-safe resume metadata, and source-server identity instead of stopping at file-plus-position checkpoints alone
• operators still needed the existing shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces to explain why a MySQL capture can resume, why it fails fast, and whether it is still pointed at the expected upstream without inventing a MySQL-only lifecycle monitor
• MySQL-specific GTID, server-identity, and checkpoint-schema seams still had to stay additive over the shipped shared CDC descriptor, runtime-state, execution-runtime, execution-graph, hosted-execution, and runtime-story contracts

Acceptance:

• Cephalon.Data.MySql keeps the same shared CDC runtime surfaces while validating retained-binlog lifecycle posture, validating optional expected source-server UUID ownership, and surfacing provider-native lifecycle plus identity answers through additive metadata instead of a new MySQL-only operator registry
• durable MySQL checkpoints keep restart-safe provider-native context such as source-server UUID, source-server id, GTID set, binlog format, and row-image posture while preserving binlogFile|position as the stable serialized checkpoint token
• provider-native runtime state, execution-runtime summaries, staged change metadata, docs, and generated reference docs all stay aligned with the richer MySQL lifecycle and resume truth while GTID-driven orchestration and broader external CDC follow-through remain later work

Delivered:

• Cephalon.Data.MySql now validates source-server identity plus retained-binlog lifecycle during provider-native execution, upgrades the Cephalon-managed checkpoint table with SourceServerUuid, SourceServerId, GtidExecutedSet, BinlogFormat, and BinlogRowImage, and publishes additive binlogLifecycle*, sourceServerIdentity*, checkpoint*, and GTID metadata through the existing shared runtime-state and execution-runtime surfaces
• MySqlBinlogCaptureOptions now supports ExpectedSourceServerUuid, descriptor metadata now exposes binlogLifecyclePolicy, sourceServerIdentityMode, and gtidMetadataMode, and the provider-native transport now distinguishes lifecycle and identity failures such as binary-logging-disabled, source-server-mismatch, and checkpoint-binlog-unavailable on the same shared runtime story
• targeted coverage now proves the hardened MySQL lifecycle and resume story through composition tests 26/26, hosting tests 2/2, tooling package-surface plus docs coverage validation, and the reference docs publish script

ENG-160 Phase 13 external CDC reporter rejoin and stale-conflict cleanup baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-155 through ENG-157 made failover, takeover, and participant-level coordination truth visible, but the shared runtime story could still carry rejected-conflict evidence or takeover-only standby participants longer than the latest accepted reporter posture warranted
• operators still needed the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces to answer the current coordination story after a successful reporter rejoin or a stable post-takeover reassertion without inventing a second cleanup coordinator
• richer operator guidance also still needed lightweight participant-count helpers on the shared coordination contract so tooling could summarize active versus standby versus rejected posture without always iterating the full participant array

Acceptance:

• Cephalon.Abstractions extends the shared CDC reporter-coordination contract with additive participant-count helpers while preserving the same participant list and takeover/degraded taxonomy
• Cephalon.Data clears stale rejected-conflict evidence after later accepted reports, keeps rejected conflicts scoped to the current accepted coordination story, and drops takeover-only standby participants after the replacement reporter reaffirms lease ownership while preserving historical takeover fields on the same shared runtime-state catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while additional provider-specific capture implementations and later external topology hardening remain later work

Delivered:

• CdcCaptureReporterCoordinationStatus now publishes additive ParticipantCount, ActiveReporterCount, StandbyReporterCount, RejectedReporterCount, and HasMultipleActiveReporters helpers over the same shared participant list and takeover/degraded contract
• Cephalon.Data now clears stale rejected-conflict evidence after later accepted reports, suppresses takeover-only standby participants once the replacement reporter has reasserted lease ownership, and keeps historical PreviousReporterId, LeaseExpiredAtUtc, and LastTakeoverObservedAtUtc available on the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces without inventing a second coordinator
• targeted coverage now proves active-reaffirmation cleanup and takeover standby normalization through composition tests 26/26, hosting tests 5/5, tooling package-surface validation, and the reference docs publish script

ENG-161 Phase 13 Oracle LogMiner provider-native CDC baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-160 left phase 13 ready for the next provider-specific capture implementation, but the shared CDC runtime story still lacked an Oracle-native relational redo-log proof alongside the shipped MongoDB, SQL Server, PostgreSQL, and MySQL runners
• operators still needed the existing /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces to answer Oracle LogMiner ownership, progress, and checkpoint truth without inventing an Oracle-only control plane or monitor
• Oracle-specific SCN windows, redo-file selection, committed-only LogMiner execution, and durable commitScn|changeScn|rsId|ssn checkpoints still had to stay additive over the shipped shared CDC descriptor, runtime-state, execution-runtime, execution-graph, hosted-execution, and runtime-story contracts

Acceptance:

• Cephalon.Data.Oracle contributes provider-native Oracle LogMiner captures through the shared CDC catalog family, keeps authored SourceModuleId truth intact, and publishes capability, execution-runtime, execution-graph, hosted-execution, and runtime-story answers on the existing shared surfaces instead of a provider-local registry
• the Oracle hosted runner resolves bounded SCN windows, selects covering redo and archive log files, stages deterministic outbox publications for committed table changes, and only persists durable commitScn|changeScn|rsId|ssn checkpoints after stage success
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while Oracle-specific lifecycle and resume hardening remain later work

Delivered:

• Cephalon.Data.Oracle now ships OracleDataOptions, OracleLogMinerCaptureOptions, AddOracleData(...), oracle-logminer-capture-flow, oracle-logminer-capture-pump, the oracle-data module, and a provider-native LogMiner hosted runner over the same shared CDC runtime story used by the existing provider packs
• Oracle runtime-state and staged change metadata now keep additive startScn, endScn, currentScn, earliestAvailableScn, resumeMode, checkpointStore, checkpointSource, logMinerDictionary, logMinerMode, redoCursor, and logFileCount truth on the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing a second operator registry
• targeted coverage now proves the Oracle provider-native CDC baseline through composition tests 27/27, hosting tests 1/1, tooling tests 263/263, and the reference docs publish script

ENG-162 Phase 13 Oracle LogMiner lifecycle and resume hardening baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-161 proved the Oracle LogMiner provider-native baseline, but the shared CDC runtime story still needed Oracle-specific lifecycle and restart truth for source identity, retained archive-log windows, and checkpoint provenance
• operators still needed the existing /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and snapshot surfaces to explain DBID, DB_UNIQUE_NAME, archive-log posture, resetlogs posture, and checkpoint-gap decisions without inventing an Oracle-only lifecycle registry
• durable checkpoint commits still had to stay additive over the shared provider-native runtime contract while preserving enough Oracle provenance to reject mismatched resumes truthfully

Acceptance:

• OracleLogMinerCaptureOptions exposes additive lifecycle controls for expected database identity and checkpoint-gap policy without changing the shared CDC descriptor/runtime contract
• the Oracle provider-native transport validates live database identity plus archive-log posture, stores restart-safe provenance on the Cephalon-managed checkpoint table, and keeps Oracle restart decisions grounded in deterministic databaseIdentity*, archiveLogLifecycle*, and checkpoint* metadata on the shared runtime surfaces
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice without reopening an Oracle-only operator registry

Delivered:

• Cephalon.Data.Oracle now supports ExpectedDatabaseId, ExpectedDatabaseUniqueName, and ResumeFromEarliestAvailableScnIfCheckpointUnavailable on OracleLogMinerCaptureOptions, projects those policies through descriptor metadata, and validates live DBID, DB_UNIQUE_NAME, ARCHIVELOG, and checkpoint provenance before one provider-native LogMiner iteration starts
• the Cephalon-managed Oracle checkpoint table now keeps additive DatabaseId, DatabaseUniqueName, ResetLogsChangeNumber, ArchiveLogMode, and SupplementalLogDataMin columns, while shared runtime-state metadata now publishes databaseIdentityState, databaseIdentityAction, archiveLogLifecycleState, archiveLogLifecycleAction, checkpointDatabase*, and checkpoint-gap policy truth on the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces without inventing a second Oracle monitor
• targeted coverage now proves the Oracle lifecycle/resume hardening baseline through composition tests 28/28, hosting tests 2/2, tooling tests 185/185, and the reference docs publish script

ENG-163 Phase 13 external and edge-aware CDC operator-story drill-down baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-155 through ENG-160 made the shared external CDC runtime story truthful for reporter failover, takeover, degraded posture, and stale-conflict cleanup, but operators still had to scan the whole /engine/cdc-captures/runtime* or /engine/cdc-capture-runtimes* catalog to answer which captures or runtimes belonged to one reporter, one edge node, or one degraded coordination posture
• hosts and tooling still needed the existing shared runtime-state and execution-runtime catalogs to answer reporter-centric and edge-centric operator questions without inventing an ASP.NET Core-only filter layer or a second coordination registry
• shared CDC operator-story drill-downs still had to stay additive over the shipped ICdcCaptureRuntimeStateCatalog, ICdcCaptureExecutionRuntimeCatalog, /engine/cdc-*, and snapshot surfaces instead of baking provider- or host-specific coordination queries into one companion pack

Acceptance:

• the shared CDC runtime-state and execution-runtime catalogs expose additive reporter, edge-node, coordination-state, and degraded-reason drill-down methods without changing the existing runtime contract shape
• ASP.NET Core publishes those same reporter, edge-node, coordination-state, and degraded-reason filters through the existing /engine/cdc-captures/runtime* and /engine/cdc-capture-runtimes* route families so operator flows can stay on the shared runtime story
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-specific capture expansion remains separate follow-through

Delivered:

• ICdcCaptureRuntimeStateCatalog now exposes GetByReporterId(...), GetByEdgeNodeId(...), GetByReporterCoordinationState(...), and GetByReporterCoordinationIssueReason(...), while ICdcCaptureExecutionRuntimeCatalog now exposes the same four additive drill-down methods over runtime-first summaries
• Cephalon.Data now projects those reporter-centric, edge-centric, coordination-state, and degraded-reason queries off the same shared runtime-state plus execution-runtime catalogs, preserving existing participant, lease, takeover, and degraded-posture truth instead of materializing a second operator cache
• Cephalon.AspNetCore now maps /engine/cdc-captures/runtime/reporters/{reporterId}, /engine/cdc-captures/runtime/edge-nodes/{edgeNodeId}, /engine/cdc-captures/runtime/reporter-coordination/{coordinationState}, /engine/cdc-captures/runtime/reporter-coordination/issues/{degradedReason}, /engine/cdc-capture-runtimes/reporters/{reporterId}, /engine/cdc-capture-runtimes/edge-nodes/{edgeNodeId}, /engine/cdc-capture-runtimes/reporter-coordination/{coordinationState}, and /engine/cdc-capture-runtimes/reporter-coordination/issues/{degradedReason} so host routes stay aligned with the same shared operator story
• targeted coverage now proves the operator-story drill-down baseline through composition tests 1/1, hosting tests 1/1, tooling tests 185/185, and the reference docs publish script

ENG-193 Phase 13 managed-connector broader provider-owned write-path execution baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, and ENG-192 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and scheduler recovery/execution-hardening truth, but operators still lacked one shared answer for whether the provider-owned write-path lane itself was executable, blocked, executing, completed, or risky on the current node
• the next follow-through needed to keep broader provider-owned write-path execution additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only provider execution registry, second coordinator, or second command lane
• later provider-owned control-plane ownership or broader provider execution orchestration still needed one truthful shared write-path answer grounded in execution-adapter, command-execution, retry-policy, automatic-retry, lease, scheduler, and recovery truth instead of forcing hosts or provider packs to re-derive provider execution posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned write-path execution contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, provider-executable, provider-blocked, provider-owned-executing, provider-owned-completed, and provider-owned-risk posture together with 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
• the shared execution-runtime catalog now exposes additive provider-owned write-path execution state, category, and operation filters while deriving that posture from the same shared execution-adapter, latest command-execution, retry-policy, automatic-retry, lease, scheduler, and recovery truth instead of forcing hosts or providers to invent another provider execution planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader provider-owned write-path execution answer so bounded background retry execution no longer trusts scheduler recovery truth alone when the merged provider lane still reports provider-blocked or provider-owned-risk
• ASP.NET Core publishes those same provider-owned write-path execution filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the write-path answer stays additive beside the existing coordination, lease, hardening, orchestration, lease-execution, scheduler, recovery, and command surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane ownership or broader provider execution orchestration remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedWritePathExecutionStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedWritePathExecution
• Cephalon.Data now derives managed-connector provider-owned write-path execution posture from merged provider execution-adapter, latest command-execution, retry-execution-policy, automatic background retry, distributed retry lease, durable shared scheduler, and scheduler recovery truth, including provider-executable, provider-blocked, provider-owned-executing, provider-owned-completed, and provider-owned-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedWritePathExecutionState(...), GetByManagedConnectorProviderOwnedWritePathExecutionCategory(...), and GetByManagedConnectorProviderOwnedWritePathExecutionOperationId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider-owned write-path execution answer so bounded background retry execution no longer depends on scheduler recovery truth alone when the merged provider answer still reports provider-blocked or provider-owned-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, recovery, command, and provider execution story
• Cephalon.Data.Debezium now participates in that broader shared provider-owned write-path lane through the existing managed-connector runtime and command surface while targeted coverage proves provider-blocked, provider-owned-executing, and provider-owned-risk posture without claiming a Debezium-only control-plane ownership subsystem
• targeted coverage now proves the broader provider-owned write-path execution baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-200 Phase 13 managed-connector provider-owned control-plane dependency-aware provisioning and mutation hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168 through ENG-199 already shipped the shared external-runtime 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, coordination, durable journal, distributed lease, orchestration, richer cross-node idempotency, broader multi-node lease-execution, durable shared scheduler, scheduler recovery, broader provider-owned write-path, provider execution orchestration, provider-owned control-plane ownership, mutation/reconcile, provisioning, apply-and-reconcile execution, and dependency-aware apply-and-reconcile hardening baselines, but operators still lacked one shared answer for whether dependency truth was strong enough to harden the broader provisioning-versus-mutation lane on the current node
• the next follow-through needed to keep provider-owned control-plane dependency-aware provisioning and mutation hardening additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only provisioning or mutation dependency-hardening subsystem
• later provider-specific control-plane materializer follow-through or broader dependency-aware teardown and mutation-execution hardening still needed one truthful shared answer grounded in the shipped provider-owned control-plane dependency-aware apply-and-reconcile hardening lane plus broader provider-owned control-plane provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, governance, drift, latest command, retry-policy, command-journal, durable-history, and reporter-lease truth

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned control-plane dependency-aware provisioning and mutation hardening contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, dependency-ready, provisioning-blocked, mutation-blocked, dependency-degraded, provisioning-hardened, mutation-hardened, and dependency-risk posture together with categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader 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, governance and drift posture, 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
• the shared execution-runtime catalog now exposes additive dependency-aware provisioning and mutation hardening state, category, and operation filters while deriving that posture from the same shared governance, drift, provider-owned control-plane dependency-aware apply-and-reconcile hardening, provider-owned control-plane apply-and-reconcile execution, provider-owned control-plane provisioning, provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, latest command-execution, retry-policy, command-journal, dependency-identity, task-topology, durable-history, and reporter-lease truth instead of forcing hosts or providers to invent another dependency evaluator
• ASP.NET Core publishes those same dependency-aware provisioning and mutation hardening filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the hardening answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, provider-owned mutation/reconcile, provider-owned provisioning, provider-owned apply-and-reconcile, and dependency-aware apply-and-reconcile surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-specific control-plane materializer follow-through or broader dependency-aware teardown and mutation-execution hardening remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardening
• Cephalon.Data now derives managed-connector provider-owned control-plane dependency-aware provisioning and mutation hardening posture from merged governance, drift, provider-owned control-plane dependency-aware apply-and-reconcile hardening, provider-owned control-plane apply-and-reconcile execution, provider-owned control-plane provisioning, provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path execution, latest command- execution, retry-execution-policy, bounded command-journal, dependency-identity, task-topology, durable-history, and reporter-lease truth, including dependency-ready, provisioning-blocked, mutation-blocked, dependency-degraded, provisioning-hardened, mutation-hardened, and dependency-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningState(...), GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareProvisioningAndMutationHardeningOperationId(...)
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared governance, drift, orchestration, command, provider-owned control-plane, and dependency-hardening story
• Cephalon.Data.Debezium now participates in that broader shared dependency-aware hardening lane through the existing managed-connector runtime and command surface while targeted coverage proves mutation-hardened and dependency-risk posture without claiming a Debezium-only provisioning/mutation dependency-hardening subsystem
• targeted coverage now proves the provider-owned control-plane dependency-aware provisioning and mutation hardening baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-208 Phase 13 managed-connector provider-specific current-node drill-down follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-201 through ENG-207 already shipped shared provider-specific materializer and dependency-aware teardown/mutation-execution posture plus dependency identity drill-down truth, but operators still had to infer current-node executability from category sets instead of drilling directly into one stable shared answer on the same /engine/cdc-capture-runtimes* family
• the next follow-through needed to keep provider-specific current-node drill-down additive on the existing shared execution-runtime catalog, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes instead of inventing a Debezium-only operator surface
• later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through still needed that current-node drill-down truth to stay grounded in the same shared catalog and route family

Acceptance:

• ICdcCaptureExecutionRuntimeCatalog exposes additive current-node filters for ManagedConnectorProviderSpecificControlPlaneMaterializer plus additive overall, teardown, and mutation-execution current-node filters for ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening
• Cephalon.AspNetCore publishes matching current-node routes for those same shared provider-specific surfaces without introducing a second coordinator, second registry, or Debezium-only API family
• targeted coverage proves the new current-node drill-downs across the shared composition and hosting stories, and docs/tracking stay aligned with the shipped slice

Delivered:

• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneMaterializerCanUseOnCurrentNode(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCanExecuteOnCurrentNode(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCanExecuteTeardownOnCurrentNode(...), and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCanExecuteMutationExecutionOnCurrentNode(...) on the same shared execution-runtime catalog
• Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/current-nodes/{canUseOnCurrentNode}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/current-nodes/{canExecuteOnCurrentNode}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/current-nodes/teardowns/{canExecuteTeardownOnCurrentNode}, and /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/current-nodes/mutation-executions/{canExecuteMutationExecutionOnCurrentNode} on the existing shared route family
• targeted coverage now proves the current-node drill-down follow-through through composition tests 2/2, hosting tests 2/2, tooling tests 207/207, and the reference docs publish script
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-207 Phase 13 managed-connector provider-specific dependency-identity drill-down follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-201 through ENG-206 already shipped shared provider-specific materializer and dependency-aware teardown/mutation-execution posture plus provider-surface, connector, worker, and transport drill-down truth, but operators still lacked one stable shared way to drill into those answers by Kafka Connect cluster id, connector class, and source-provider id on the same /engine/cdc-capture-runtimes* family
• the next follow-through needed to keep provider-specific dependency identity drill-down additive on the existing shared execution-runtime catalog, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes instead of inventing a Debezium-only operator surface
• later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through still needed that dependency-identity drill-down truth to stay grounded in the same shared catalog and route family

Acceptance:

• ICdcCaptureExecutionRuntimeCatalog exposes additive connect-cluster, connector-class, and source-provider filters for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening
• Cephalon.AspNetCore publishes matching dependency-identity routes for those same two shared provider-specific surfaces without introducing a second coordinator, second registry, or Debezium-only API family
• targeted coverage proves the new dependency-identity drill-downs across the shared composition and hosting stories, and docs/tracking stay aligned with the shipped slice

Delivered:

• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneMaterializerConnectClusterId(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerConnectorClass(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerSourceProviderId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningConnectClusterId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningConnectorClass(...), and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningSourceProviderId(...) on the same shared execution-runtime catalog
• Cephalon.AspNetCore now publishes /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/connect-clusters/{connectClusterId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/connector-classes/{connectorClass}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/source-providers/{sourceProviderId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/connect-clusters/{connectClusterId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/connector-classes/{connectorClass}, and /engine/cdc-capture-runtimes/provider-specific-control-plane-dependency-aware-teardown-and-mutation-execution-hardenings/source-providers/{sourceProviderId} on the existing shared route family
• targeted coverage now proves the dependency-identity drill-down follow-through through composition tests 2/2, hosting tests 2/2, tooling tests 207/207, and the reference docs publish script
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-206 Phase 13 managed-connector provider-specific transport identity drill-down follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-201 through ENG-205 already shipped shared provider-specific materializer and dependency-aware teardown/mutation-execution posture plus provider-surface, connector, and worker drill-down truth, but operators still lacked one stable shared way to drill into those answers by transport kind on the same /engine/cdc-capture-runtimes* family
• the next follow-through needed to keep provider-specific transport identity drill-down additive on the existing shared execution-runtime catalog, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes instead of inventing a Debezium-only operator surface
• later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through still needed that transport drill-down truth to stay grounded in the same shared catalog and route family

Acceptance:

• ICdcCaptureExecutionRuntimeCatalog exposes additive transport-kind filters for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening
• Cephalon.AspNetCore publishes matching transport routes for those same two shared provider-specific surfaces without introducing a second coordinator, second registry, or Debezium-only API family
• targeted coverage proves the new transport drill-downs across the shared composition and hosting stories, and docs/tracking stay aligned with the shipped slice

Delivered:

• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneMaterializerTransportKind(...) and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningTransportKind(...) on the same shared execution-runtime catalog
• 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} on the existing shared route family
• targeted coverage now proves the transport drill-down follow-through through composition tests 2/2, hosting tests 2/2, tooling tests 207/207, and the reference docs publish script
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-205 Phase 13 managed-connector provider-specific worker identity drill-down follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-201 through ENG-204 already shipped shared provider-specific materializer and dependency-aware teardown/mutation-execution posture plus truthful worker identity, but operators still lacked one stable shared way to drill into those answers by worker id on the same /engine/cdc-capture-runtimes* family
• the next follow-through needed to keep provider-specific worker identity drill-down additive on the existing shared execution-runtime catalog, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes instead of inventing a Debezium-only operator surface
• later provider-specific transport drill-down or broader provider-specific teardown and mutation-execution follow-through still needed that worker drill-down truth to stay grounded in the same shared catalog and route family

Acceptance:

• ICdcCaptureExecutionRuntimeCatalog exposes additive worker-id filters for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening
• Cephalon.AspNetCore publishes matching worker routes for those same two shared provider-specific surfaces without introducing a second coordinator, second registry, or Debezium-only API family
• targeted coverage proves the new worker drill-downs across the shared composition and hosting stories, and docs/tracking stay aligned with the shipped slice

Delivered:

• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneMaterializerWorkerId(...) and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningWorkerId(...) on the same shared execution-runtime catalog
• 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} on the existing shared route family
• targeted coverage now proves the worker drill-down follow-through through composition tests 2/2, hosting tests 2/2, tooling tests 207/207, and the reference docs publish script
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-specific transport drill-down or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-204 Phase 13 managed-connector provider-specific worker identity normalization follow-through baseline

Status: done Estimate: 5 Completed: April 25, 2026

Why:

• ENG-201 and ENG-202 already shipped shared provider-specific materializer and dependency-aware teardown/mutation-execution posture, but Debezium external reports could still omit raw workerId metadata even when the stable external reporterId was already known on the same shared runtime story
• the next follow-through needed to keep worker identity truthful on the existing shared execution-runtime catalog, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes instead of collapsing provider-specific worker posture back to missing identity whenever a report omitted that one metadata field
• later worker and transport drill-down follow-through still needed worker identity normalization to stay grounded in the same shared report-sink and execution-runtime catalog path

Acceptance:

• Cephalon.Data.Debezium normalizes provider-specific worker identity through the existing report sink by falling back from raw workerId metadata to the stable external reporterId
• the shared execution-runtime catalog resolves the best available provider-specific worker id from normalized metadata plus active reporter truth for both provider-specific materializer and dependency-aware teardown/mutation-execution hardening posture
• targeted coverage proves worker identity stays visible across external report ingestion and the existing automatic retry execution story, and docs/tracking stay aligned with the shipped slice

Delivered:

• DebeziumExecutionRuntimeReportSink now falls back from raw workerId metadata to the stable external reporterId when normalizing provider-specific control-plane observations
• the shared execution-runtime catalog now resolves the best available provider-specific worker id from normalized provider-specific metadata plus active reporter truth, keeping WorkerIdentityVisible, WorkerId, and HasWorkerIdentity aligned for both shared provider-specific control-plane surfaces
• targeted coverage now proves the worker identity normalization follow-through through composition tests 2/2, hosting tests 2/2, tooling tests 207/207, and the reference docs publish script
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later worker/transport drill-down or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-203 Phase 13 managed-connector provider-specific control-plane identity drill-down follow-through baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-201 and ENG-202 already shipped shared provider-specific materializer and dependency-aware teardown/mutation-execution posture, but operators still lacked one stable shared way to drill into those answers by provider-surface id or connector id on the same /engine/cdc-capture-runtimes* family
• the next follow-through needed to keep provider-specific identity drill-down additive on the existing shared execution-runtime catalog, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes instead of inventing a Debezium-only operator surface
• later additional provider-specific materializers or broader provider-specific teardown and mutation-execution follow-through still needed that provider-surface and connector drill-down truth to stay grounded in the same shared catalog and route family

Acceptance:

• ICdcCaptureExecutionRuntimeCatalog exposes additive provider-surface and connector filters for both ManagedConnectorProviderSpecificControlPlaneMaterializer and ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening
• Cephalon.AspNetCore publishes matching provider-surface and connector routes for those same two shared provider-specific surfaces without introducing a second coordinator, second registry, or Debezium-only API family
• targeted coverage proves the new provider-surface and connector drill-downs across the shared composition and hosting stories, and docs/tracking stay aligned with the shipped slice

Delivered:

• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneMaterializerProviderSurfaceId(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerConnectorId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningProviderSurfaceId(...), and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningConnectorId(...) on the same shared execution-runtime catalog
• 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} on the existing shared route family
• targeted coverage now proves the identity drill-down follow-through through composition tests 2/2, hosting tests 2/2, tooling tests 207/207, and the reference docs publish script
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-202 Phase 13 managed-connector provider-specific control-plane dependency-aware teardown and mutation-execution hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168 through ENG-201 already shipped the shared external-runtime 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, coordination, durable journal, distributed lease, orchestration, richer cross-node idempotency, broader multi-node lease-execution, durable shared scheduler, scheduler recovery, broader provider-owned write-path, provider execution orchestration, provider-owned control-plane ownership, mutation/reconcile, provisioning, apply-and-reconcile execution, dependency-aware apply-and-reconcile hardening, dependency-aware provisioning and mutation hardening, and provider-specific control-plane materializer baselines, but operators still lacked one shared answer for whether the selected provider-specific materializer could execute dependency-aware teardown or mutation work safely on the current node
• the next follow-through needed to keep provider-specific teardown and mutation-execution hardening additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only teardown or mutation-execution subsystem
• later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through still needed one truthful shared answer grounded in provider-specific materializer identity plus the shipped provider-owned control-plane dependency-aware provisioning and mutation hardening, apply-and-reconcile, provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, latest command, retry-policy, command-journal, durable-history, and reporter-lease truth

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-specific control-plane dependency-aware teardown and mutation-execution hardening contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, dependency-ready, teardown-blocked, mutation-execution-blocked, dependency-degraded, teardown-hardened, mutation-execution-hardened, and dependency-risk posture together with state/category/provider/materializer/operation filters
• Cephalon.Data derives that hardening truth from the shipped provider-specific materializer posture plus provider-owned control-plane dependency-aware provisioning and mutation hardening, apply-and-reconcile, provisioning, mutation/reconcile, ownership, execution orchestration, provider-owned write-path, latest command, retry-policy, command-journal, durable-history, and reporter-lease evidence without introducing a second coordinator or second registry
• the shared execution-runtime story keeps provider/materializer/transport/provider-surface/ connector/worker identity plus current-node capability booleans visible, so hosts and provider packs can read one stable dependency-aware teardown-versus-mutation-execution answer instead of re-deriving the same provider-specific control-plane truth in separate control-plane code
• Cephalon.AspNetCore extends the existing CDC runtime surface with provider-specific dependency-aware teardown and mutation-execution hardening routes for state, category, provider, materializer, operation, and per-runtime detail without introducing a Debezium-only control-plane API family, second coordinator, or second registry

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardening
• Cephalon.Data now derives managed-connector provider-specific control-plane dependency-aware teardown and mutation-execution hardening posture from merged provider-specific materializer plus provider-owned control-plane dependency-aware provisioning and mutation hardening, apply-and-reconcile execution, provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, latest command-execution, retry-execution-policy, command-journal, durable-history, reporter-lease, and normalized provider/materializer/transport/provider-surface/connector/ worker identity truth
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningState(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningCategory(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningProviderId(...), GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningMaterializerId(...), and GetByManagedConnectorProviderSpecificControlPlaneDependencyAwareTeardownAndMutationExecutionHardeningOperationId(...) on the shared execution-runtime surface instead of forcing hosts or providers to invent a separate teardown or mutation-execution hardening selector
• 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/materializers/{materializerId}, /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 same shared route family without introducing a second coordinator, second registry, or Debezium-only teardown/mutation-execution endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later additional provider-specific control-plane materializers or broader provider-specific teardown and mutation-execution follow-through remain separate

ENG-201 Phase 13 managed-connector provider-specific control-plane materializer follow-through baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168 through ENG-200 already shipped the shared external-runtime 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, coordination, durable journal, distributed lease, orchestration, richer cross-node idempotency, broader multi-node lease-execution, durable shared scheduler, scheduler recovery, broader provider-owned write-path, provider execution orchestration, provider-owned control-plane ownership, mutation/reconcile, provisioning, apply-and-reconcile execution, dependency-aware apply-and-reconcile hardening, and dependency-aware provisioning and mutation hardening baselines, but operators still lacked one shared answer for which provider-specific control-plane materializer identity and provider surface should own the current runtime on the current node
• the next follow-through needed to keep provider-specific control-plane materializer truth additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only materializer subsystem
• later broader dependency-aware teardown and mutation-execution hardening still needed one truthful shared answer grounded in provider-specific materializer identity plus the shipped provider-owned control-plane dependency-aware provisioning and mutation hardening, apply-and-reconcile, provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, latest command, retry-policy, command-journal, durable-history, and reporter-lease truth

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-specific control-plane materializer contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, materializer-unavailable, materializer-ready, materializer-selected, materializer-executing, and materializer-risk posture together with categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader provider-owned control-plane dependency-aware provisioning and mutation hardening plus upstream provider-owned control-plane truth, provider-specific provider/materializer/transport/provider-surface/connector/worker identity, durable-history plus reporter-lease signals, and CanUseProviderSpecificControlPlaneMaterializerOnCurrentNode
• the shared execution-runtime catalog now exposes additive provider-specific control-plane materializer state, category, provider, materializer, and operation filters while deriving that posture from the same broader dependency-aware provisioning and mutation hardening, apply-and-reconcile execution, provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, latest command-execution, retry-execution-policy, command-journal, durable-history, reporter-lease, and normalized provider-specific identity truth instead of forcing hosts or providers to invent another materializer selector
• ASP.NET Core publishes those same provider-specific control-plane materializer filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down, provider filters, and materializer filters, and the materializer answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned control-plane, and dependency-hardening surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later broader dependency-aware teardown and mutation-execution hardening remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerStates, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderSpecificControlPlaneMaterializerStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderSpecificControlPlaneMaterializer
• Cephalon.Data now derives managed-connector provider-specific control-plane materializer posture from merged provider-owned control-plane dependency-aware provisioning and mutation hardening, apply-and-reconcile execution, provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path execution, latest command-execution, retry-execution-policy, bounded command-journal, durable-history, reporter-lease, and normalized provider-specific identity truth, including materializer-ready, materializer-selected, materializer-executing, and materializer-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderSpecificControlPlaneMaterializerState(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerCategory(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerProviderId(...), GetByManagedConnectorProviderSpecificControlPlaneMaterializerId(...), and GetByManagedConnectorProviderSpecificControlPlaneMaterializerOperationId(...)
• Cephalon.Data.Debezium now normalizes provider-specific control-plane provider, materializer, transport, provider-surface, connector, and worker identity through the existing contributor plus report-sink lane so the shared runtime surface can select the Debezium Kafka Connect REST materializer without claiming a Debezium-only control-plane subsystem
• Cephalon.AspNetCore now maps /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/materializers/{materializerId}, /engine/cdc-capture-runtimes/provider-specific-control-plane-materializers/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/provider-specific-control-plane-materializer so host routes stay aligned with the same shared provider-owned control-plane and dependency-hardening story
• targeted coverage now proves the provider-specific control-plane materializer baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-199 Phase 13 managed-connector provider-owned control-plane dependency-aware apply-and-reconcile hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, ENG-192, ENG-193, ENG-194, ENG-195, ENG-196, ENG-197, and ENG-198 already shipped shared coverage, remediation, governance, desired-versus-observed 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 truth, broader provider execution orchestration truth, provider-owned control-plane ownership truth, provider-owned control-plane mutation/reconcile truth, provider-owned control-plane provisioning truth, and provider-owned control-plane apply-and-reconcile execution truth, but operators still lacked one shared answer for whether declared-versus- reported dependency identity, task topology, durable command evidence, and active reporter-lease truth were strong enough to harden one bounded provider-owned control-plane apply-and-reconcile lane on the current node
• the next follow-through needed to keep provider-owned control-plane dependency-aware apply-and-reconcile hardening additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only dependency analyzer, second coordinator, or second control-plane registry
• later provider-owned control-plane dependency-aware provisioning and mutation hardening still needed one truthful shared dependency answer grounded in the shipped provider-owned control-plane apply-and-reconcile execution lane plus broader provider-owned control-plane provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, governance, drift, latest command, retry-policy, command-journal, and reporter-lease truth instead of forcing hosts or provider packs to re-derive broader dependency posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned control-plane dependency-aware apply-and-reconcile hardening contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, dependency-ready, dependency-blocked, dependency-degraded, apply-and-reconcile-hardened, and dependency-risk posture together with categories, execution-runtime and capture identity, ownership/topology, management mode, operation/source, broader provider-owned control-plane apply-and-reconcile plus provisioning plus mutation/reconcile plus ownership plus execution-orchestration plus write-path truth, governance and drift posture, latest command plus retry-policy plus command-journal evidence, declared-versus-reported dependency identity and task-topology metadata, active reporter-lease evidence, durable-history signals, and CanExecuteDependencyAwareApplyAndReconcileOnCurrentNode
• the shared execution-runtime catalog now exposes additive dependency-aware apply-and-reconcile hardening state, category, and operation filters while deriving that posture from the same shared governance, drift, provider-owned control-plane apply-and-reconcile execution, provider-owned control-plane provisioning, provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, latest command-execution, retry-policy, command-journal, dependency-identity, task topology, and reporter-lease truth instead of forcing hosts or providers to invent another dependency evaluator
• ASP.NET Core publishes those same dependency-aware apply-and-reconcile hardening filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the hardening answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, provider-owned mutation/reconcile, provider-owned provisioning, and provider-owned apply-and-reconcile execution surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane dependency-aware provisioning and mutation hardening follow-through remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardening
• Cephalon.Data now derives managed-connector provider-owned control-plane dependency-aware apply-and-reconcile hardening posture from merged governance, drift, provider-owned control-plane apply-and-reconcile execution, provider-owned control-plane provisioning, provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path execution, latest command-execution, retry-execution-policy, bounded command-journal, dependency-identity, task-topology, and reporter-lease truth, including dependency-ready, dependency-blocked, dependency-degraded, apply-and-reconcile-hardened, and dependency-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningState(...), GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneDependencyAwareApplyAndReconcileHardeningOperationId(...)
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared governance, drift, orchestration, command, provider-owned control-plane, and dependency-hardening story
• Cephalon.Data.Debezium now participates in that broader shared dependency-aware hardening lane through the existing managed-connector runtime and command surface while targeted coverage proves apply-and-reconcile-hardened and dependency-risk posture without claiming a Debezium-only dependency-hardening subsystem
• targeted coverage now proves the provider-owned control-plane dependency-aware apply-and-reconcile hardening baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-198 Phase 13 managed-connector provider-owned control-plane apply-and-reconcile execution baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, ENG-192, ENG-193, ENG-194, ENG-195, ENG-196, and ENG-197 already shipped shared coverage, remediation, governance, desired-versus-observed 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 truth, broader provider execution orchestration truth, provider-owned control-plane ownership truth, provider-owned control-plane mutation/reconcile truth, and provider-owned control-plane provisioning truth, but operators still lacked one shared answer for whether Cephalon could safely execute one bounded provider-owned control-plane apply-and-reconcile step on the current node without pushing that execution story into hosts or a Debezium-only subsystem
• the next follow-through needed to keep provider-owned control-plane apply-and-reconcile execution additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only execution registry, second coordinator, or second command lane
• later provider-owned control-plane dependency-aware provisioning and mutation hardening still needed one truthful shared dependency answer grounded in the shipped provider-owned control-plane apply-and-reconcile execution lane plus broader provider-owned control-plane provisioning, mutation/reconcile, ownership, provider execution orchestration, provider-owned write-path, governance, drift, latest command, retry-policy, command-journal, durable scheduler, recovery, and reporter-lease truth instead of forcing hosts or provider packs to re-derive broader dependency posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned control-plane apply-and-reconcile execution contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, apply-and-reconcile-ready, apply-and-reconcile-blocked, apply-and-reconcile-executing, apply-and-reconcile-completed, and apply-and-reconcile-risk posture together with 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
• the shared execution-runtime catalog now exposes additive provider-owned control-plane apply-and-reconcile execution state, category, and operation filters while deriving that posture from the same shared provider-owned control-plane provisioning, provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, command-envelope, command-issuance, latest command-execution, retry-policy, command-journal, durable shared scheduler, and scheduler-recovery truth instead of forcing hosts or providers to invent another execution planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader provider-owned control-plane apply-and-reconcile execution answer so bounded background retry execution no longer trusts provider-owned control-plane provisioning truth alone when the merged apply-and-reconcile lane still reports apply-and-reconcile-blocked, apply-and-reconcile-completed, or apply-and-reconcile-risk
• ASP.NET Core publishes those same provider-owned control-plane apply-and-reconcile execution filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the apply-and-reconcile execution answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, provider-owned mutation/reconcile, and provider-owned provisioning surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane dependency-aware provisioning and mutation hardening follow-through remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecution
• Cephalon.Data now derives managed-connector provider-owned control-plane apply-and-reconcile execution posture from merged provider-owned control-plane provisioning, provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path execution, command-envelope, command-issuance, latest command-execution, retry-execution-policy, and bounded command-journal truth, including apply-and-reconcile-ready, apply-and-reconcile-blocked, apply-and-reconcile-executing, apply-and-reconcile-completed, and apply-and-reconcile-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionState(...), GetByManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneApplyAndReconcileExecutionOperationId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider-owned control-plane apply-and-reconcile execution answer so bounded background retry execution no longer depends on provider-owned control-plane provisioning truth alone when the merged apply-and-reconcile lane still reports apply-and-reconcile-blocked, apply-and-reconcile-completed, or apply-and-reconcile-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, provider-owned mutation/reconcile, provider-owned provisioning, and provider-owned apply-and-reconcile execution story
• Cephalon.Data.Debezium now participates in that broader shared provider-owned control-plane apply-and-reconcile execution lane through the existing managed-connector runtime and command surface while targeted coverage proves apply-and-reconcile-ready, apply-and-reconcile-executing, and apply-and-reconcile-risk posture without claiming a Debezium-only apply-and-reconcile execution subsystem
• targeted coverage now proves the provider-owned control-plane apply-and-reconcile execution baseline through composition tests 42/42, hosting tests 12/12, tooling tests 207/207, and the reference docs publish script

ENG-197 Phase 13 managed-connector provider-owned control-plane provisioning baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, ENG-192, ENG-193, ENG-194, ENG-195, and ENG-196 already shipped shared coverage, remediation, governance, desired-versus-observed 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 truth, broader provider execution orchestration truth, provider-owned control-plane ownership truth, and provider-owned control-plane mutation/reconcile truth, but operators still lacked one shared answer for whether Cephalon could safely stage provider-owned control-plane provisioning on the current node without pushing that provisioning story into hosts or a Debezium-only subsystem
• the next follow-through needed to keep provider-owned control-plane provisioning additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only provisioning registry, second coordinator, or second command lane
• later provider-owned control-plane apply-and-reconcile execution still needed one truthful shared provisioning answer grounded in provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, command-envelope, command-issuance, command-execution, retry-policy, command-journal, durable scheduler, and recovery truth instead of forcing hosts or provider packs to re-derive provisioning posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned control-plane provisioning contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, provisioning-ready, provisioning-blocked, provisioning-executing, provisioning-partial, and provisioning-risk posture together with 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
• the shared execution-runtime catalog now exposes additive provider-owned control-plane provisioning state, category, and operation filters while deriving that posture from the same shared provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, command-envelope, command-issuance, latest command-execution, retry-policy, command-journal, durable shared scheduler, and scheduler-recovery truth instead of forcing hosts or providers to invent another provisioning planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader provider-owned control-plane provisioning answer so bounded background retry execution no longer trusts provider-owned control-plane mutation/reconcile truth alone when the merged provisioning lane still reports provisioning-blocked, provisioning-partial, or provisioning-risk
• ASP.NET Core publishes those same provider-owned control-plane provisioning filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the provisioning answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, and provider-owned mutation/reconcile surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane apply-and-reconcile execution follow-through remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneProvisioningStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneProvisioning
• Cephalon.Data now derives managed-connector provider-owned control-plane provisioning posture from merged provider-owned control-plane mutation/reconcile, provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path execution, command-envelope, command-issuance, latest command-execution, retry-execution-policy, and bounded command-journal truth, including provisioning-ready, provisioning-blocked, provisioning-executing, provisioning-partial, and provisioning-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedControlPlaneProvisioningState(...), GetByManagedConnectorProviderOwnedControlPlaneProvisioningCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneProvisioningOperationId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider-owned control-plane provisioning answer so bounded background retry execution no longer depends on provider-owned control-plane mutation/reconcile truth alone when the merged provisioning lane still reports provisioning-blocked, provisioning-partial, or provisioning-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, provider-owned mutation/reconcile, and provider-owned provisioning story
• Cephalon.Data.Debezium now participates in that broader shared provider-owned control-plane provisioning lane through the existing managed-connector runtime and command surface while targeted coverage proves provisioning-partial, provisioning-executing, and provisioning-risk posture without claiming a Debezium-only provider-owned control-plane provisioning subsystem
• targeted coverage now proves the provider-owned control-plane provisioning baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-196 Phase 13 managed-connector provider-owned control-plane mutation/reconcile baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, ENG-192, ENG-193, ENG-194, and ENG-195 already shipped shared coverage, remediation, governance, desired-versus-observed 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 truth, broader provider execution orchestration truth, and broader provider-owned control-plane ownership truth, but operators still lacked one shared answer for whether Cephalon could safely mutate or reconcile provider-owned control-plane state on the current node without pushing that mutation/reconcile story into hosts or a Debezium-only subsystem
• the next follow-through needed to keep provider-owned control-plane mutation/reconcile additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only mutation registry, second coordinator, or second command lane
• later provider-owned control-plane provisioning work still needed one truthful shared mutation/reconcile answer grounded in provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, command-envelope, command-issuance, command-execution, retry-policy, command-journal, durable scheduler, and recovery truth instead of forcing hosts or provider packs to re-derive mutation/reconcile posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned control-plane mutation/reconcile contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, mutation-ready, reconcile-ready, mutation-blocked, reconcile-blocked, mutation-executing, and mutation-risk posture together with 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
• the shared execution-runtime catalog now exposes additive provider-owned control-plane mutation/reconcile state, category, and operation filters while deriving that posture from the same shared provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path, command-envelope, command-issuance, latest command-execution, retry-policy, command-journal, durable shared scheduler, and scheduler-recovery truth instead of forcing hosts or providers to invent another mutation/reconcile planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader provider-owned control-plane mutation/reconcile answer so bounded background retry execution no longer trusts provider-owned control-plane ownership truth alone when the merged mutation/reconcile lane still reports mutation-blocked, reconcile-blocked, or mutation-risk
• ASP.NET Core publishes those same provider-owned control-plane mutation/reconcile filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the mutation/reconcile answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, and provider-owned control-plane ownership surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane provisioning follow-through remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneMutationReconcileStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneMutationReconcile
• Cephalon.Data now derives managed-connector provider-owned control-plane mutation/reconcile posture from merged provider-owned control-plane ownership, provider execution orchestration, provider-owned write-path execution, command-envelope, command-issuance, latest command-execution, retry-execution-policy, and bounded command-journal truth, including mutation-ready, reconcile-ready, mutation-blocked, reconcile-blocked, mutation-executing, and mutation-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedControlPlaneMutationReconcileState(...), GetByManagedConnectorProviderOwnedControlPlaneMutationReconcileCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneMutationReconcileOperationId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider-owned control-plane mutation/reconcile answer so bounded background retry execution no longer depends on provider-owned control-plane ownership truth alone when the merged mutation/reconcile lane still reports mutation-blocked, reconcile-blocked, or mutation-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, provider-owned control-plane ownership, and provider-owned mutation/reconcile story
• Cephalon.Data.Debezium now participates in that broader shared provider-owned control-plane mutation/reconcile lane through the existing managed-connector runtime and command surface while targeted coverage proves mutation-ready, reconcile-ready, mutation-blocked, reconcile-blocked, mutation-executing, and mutation-risk posture without claiming a Debezium-only provider-owned control-plane mutation/reconcile subsystem
• targeted coverage now proves the provider-owned control-plane mutation/reconcile baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-195 Phase 13 managed-connector provider-owned control-plane ownership baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, ENG-192, ENG-193, and ENG-194 already shipped shared coverage, remediation, governance, desired-versus-observed 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 truth, and broader provider execution orchestration truth, but operators still lacked one shared answer for whether Cephalon could safely exercise bounded provider-owned control-plane work on the current node without pushing that ownership story into hosts or a Debezium-only subsystem
• the next follow-through needed to keep provider-owned control-plane ownership additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only ownership registry, second coordinator, or second command lane
• later provider-owned control-plane mutation, reconcile, or provisioning work still needed one truthful shared ownership answer grounded in provider execution orchestration, provider-owned write-path, execution-adapter, command-execution, retry-policy, command-journal, durable scheduler, and recovery truth instead of forcing hosts or provider packs to re-derive control-plane ownership outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider-owned control-plane ownership contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, ownership-ready, ownership-blocked, ownership-active, ownership-partial, and ownership-risk posture together with 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
• the shared execution-runtime catalog now exposes additive provider-owned control-plane ownership state, category, and operation filters while deriving that posture from the same shared provider execution orchestration, provider-owned write-path, execution-adapter, latest command-execution, retry-policy, command-journal, durable shared scheduler, and scheduler-recovery truth instead of forcing hosts or providers to invent another ownership planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader provider-owned control-plane ownership answer so bounded background retry execution no longer trusts provider execution orchestration truth alone when the merged ownership lane still reports ownership-blocked or ownership-risk
• ASP.NET Core publishes those same provider-owned control-plane ownership filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the ownership answer stays additive beside the existing coordination, lease, hardening, orchestration, scheduler, recovery, command, provider-owned write-path, and provider execution surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane mutation, reconcile, or provisioning follow-through remains separate

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipStates, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderOwnedControlPlaneOwnershipStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderOwnedControlPlaneOwnership
• Cephalon.Data now derives managed-connector provider-owned control-plane ownership posture from merged provider execution orchestration, provider-owned write-path execution, execution-adapter, latest command-execution, retry-execution-policy, bounded command-journal, durable shared scheduler, and scheduler recovery truth, including ownership-ready, ownership-blocked, ownership-active, ownership-partial, and ownership-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderOwnedControlPlaneOwnershipState(...), GetByManagedConnectorProviderOwnedControlPlaneOwnershipCategory(...), and GetByManagedConnectorProviderOwnedControlPlaneOwnershipOperationId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider-owned control-plane ownership answer so bounded background retry execution no longer depends on provider execution orchestration truth alone when the merged provider ownership lane still reports ownership-blocked or ownership-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, recovery, command, provider-owned write-path, provider execution, and provider-owned control-plane story
• Cephalon.Data.Debezium now participates in that broader shared provider-owned control-plane ownership lane through the existing managed-connector runtime and command surface while targeted coverage proves ownership-ready, ownership-active, ownership-partial, and ownership-risk posture without claiming a Debezium-only provider-owned control-plane subsystem
• targeted coverage now proves the provider-owned control-plane ownership baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-194 Phase 13 managed-connector broader provider execution orchestration hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, ENG-191, ENG-192, and ENG-193 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and broader provider-owned write-path truth, but operators still lacked one shared answer for whether the broader provider execution orchestration lane itself was ready, blocked, executing, completed, or risky on the current node
• the next follow-through needed to keep broader provider execution orchestration additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only provider orchestration registry, second coordinator, or second command lane
• later provider-owned control-plane ownership still needed one truthful shared orchestration answer grounded in provider-owned write-path, execution-adapter, command-execution, retry-policy, command-journal, durable scheduler, and recovery truth instead of forcing hosts or provider packs to re-derive orchestration posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector provider execution orchestration contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, orchestration-ready, orchestration-blocked, orchestration-executing, orchestration-completed, and orchestration-risk posture together with 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
• the shared execution-runtime catalog now exposes additive provider execution orchestration state, category, and operation filters while deriving that posture from the same shared provider-owned write-path, execution-adapter, latest command-execution, retry-policy, command-journal, durable shared scheduler, and scheduler-recovery truth instead of forcing hosts or providers to invent another orchestration planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader provider execution orchestration answer so bounded background retry execution no longer trusts provider-owned write-path truth alone when the merged orchestration lane still reports orchestration-blocked or orchestration-risk
• ASP.NET Core publishes those same provider execution orchestration filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and operation filters, and the orchestration answer stays additive beside the existing coordination, lease, hardening, orchestration, lease-execution, scheduler, recovery, command, and provider execution surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later provider-owned control-plane ownership remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorProviderExecutionOrchestrationStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorProviderExecutionOrchestration
• Cephalon.Data now derives managed-connector provider execution orchestration posture from merged provider-owned write-path execution, execution-adapter, latest command-execution, retry-execution-policy, bounded command-journal, durable shared scheduler, and scheduler recovery truth, including orchestration-ready, orchestration-blocked, orchestration-executing, orchestration-completed, and orchestration-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorProviderExecutionOrchestrationState(...), GetByManagedConnectorProviderExecutionOrchestrationCategory(...), and GetByManagedConnectorProviderExecutionOrchestrationOperationId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader provider execution orchestration answer so bounded background retry execution no longer depends on provider-owned write-path truth alone when the merged provider answer still reports orchestration-blocked or orchestration-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, recovery, command, provider-owned write-path, and provider execution story
• Cephalon.Data.Debezium now participates in that broader shared provider orchestration lane through the existing managed-connector runtime and command surface while targeted coverage proves orchestration-ready, orchestration-executing, and orchestration-risk posture without claiming a Debezium-only control-plane ownership subsystem
• targeted coverage now proves the broader provider execution orchestration baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-192 Phase 13 managed-connector scheduler recovery / execution hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, ENG-190, and ENG-191 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and durable shared scheduler-orchestration truth, but operators still lacked one shared answer for whether the current node had recovered enough durable evidence to resume bounded execution safely
• the next follow-through needed to keep scheduler recovery and execution hardening additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only recovery registry, second coordinator, or second recovery lane
• later broader provider-owned write-path execution also needed one truthful shared recovery answer grounded in durable scheduler, lease-execution, orchestration, journal, and latest command history truth instead of forcing hosts or provider packs to re-derive recovery posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector scheduler recovery and execution hardening contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, recovery-ready, recovery-blocked, replaying, execution-hardened, and execution-risk posture together with categories, execution-runtime and capture identity, ownership/topology, operation, coordination-owner and active-reporter identity, durable scheduler, broader multi-node lease-execution, distributed retry orchestration, command-journal durability, latest command-execution truth, scheduler identity and kind, retry fingerprint, latest automatic-attempt evidence, durable-history truth, and CanExecuteAutomaticRetryOnCurrentNode
• the shared execution-runtime catalog now exposes additive scheduler recovery state, category, owner, and retry-fingerprint filters while deriving that posture from the same shared durable scheduler, lease-execution, orchestration, durability, and latest command-execution truth instead of forcing hosts or providers to invent another recovery planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that scheduler recovery answer so bounded background retry execution no longer trusts durable shared scheduler truth alone when merged durable evidence or latest automatic execution still says the current node remains blocked or at risk
• ASP.NET Core publishes those same scheduler recovery filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down and retry fingerprint filters, and the recovery answer stays additive beside the existing coordination, lease, hardening, orchestration, lease-execution, and scheduler surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later broader provider-owned write-path execution remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorSchedulerRecoveryExecutionHardeningStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorSchedulerRecoveryExecutionHardening
• Cephalon.Data now derives managed-connector scheduler recovery and execution-hardening posture from merged durable shared scheduler, broader multi-node lease-execution, distributed retry orchestration, command-journal durability, and latest command-execution truth, including recovery-ready, recovery-blocked, replaying, execution-hardened, and execution-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorSchedulerRecoveryExecutionHardeningState(...), GetByManagedConnectorSchedulerRecoveryExecutionHardeningCategory(...), GetByManagedConnectorSchedulerRecoveryExecutionHardeningOwnerId(...), and GetByManagedConnectorSchedulerRecoveryExecutionHardeningRetryFingerprint(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader scheduler recovery answer so bounded background retry execution no longer depends on durable shared scheduler truth alone when the merged recovery answer still reports recovery-blocked or execution-risk
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, orchestration, scheduler, durability, and recovery story
• Cephalon.Data.Debezium now participates in that broader shared recovery lane through the existing managed-connector runtime and command surface while targeted coverage proves execution-hardened, recovery-blocked, and replaying-ready recovery posture without claiming a Debezium-only recovery subsystem
• targeted coverage now proves the scheduler recovery and execution-hardening baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-191 Phase 13 managed-connector durable shared scheduler orchestration baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, ENG-189, and ENG-190 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and broader multi-node lease-execution truth, but operators still lacked one shared answer for whether the bounded retry lane should remain durably scheduled on the current node once those earlier lease, hardening, orchestration, and durability answers were all merged together
• the next follow-through needed to keep durable shared scheduler orchestration additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only scheduler registry, second coordinator, or second scheduler lane
• later scheduler recovery/execution hardening and broader provider-owned write-path execution also needed one truthful shared scheduler answer grounded in coordination-owner, active-reporter, lease-execution, and durable-history truth instead of forcing hosts or provider packs to re-derive scheduling posture outside the shared runtime catalog

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector durable shared scheduler-orchestration contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, disabled, operator-only, unscheduled, scheduled, lease-blocked, recovery-needed, and scheduler-conflicted posture together with scheduler categories, execution-runtime and capture identity, ownership/topology, operation, coordination-owner and active-reporter identity, scheduler identity/kind, polling cadence, retry fingerprint, latest automatic-attempt evidence, durable-history truth, and CanScheduleAutomaticRetryOnCurrentNode
• the shared execution-runtime catalog now exposes additive durable shared scheduler state, category, and owner filters while deriving that posture from the same shared automatic-retry coordination, command-journal durability, distributed retry orchestration, and broader multi-node lease-execution truth instead of forcing hosts or providers to invent another scheduler planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that durable shared scheduler answer so scheduling no longer trusts broader multi-node lease-execution truth alone when merged recovery or scheduler-conflict evidence still says the current node should remain blocked
• ASP.NET Core publishes those same durable shared scheduler filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down, and the scheduler answer stays additive beside the existing coordination, lease, hardening, orchestration, and lease-execution surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later scheduler recovery/execution hardening or broader provider-owned write-path execution remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorDurableSharedSchedulerOrchestrationStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDurableSharedSchedulerOrchestration
• Cephalon.Data now derives managed-connector durable shared scheduler-orchestration posture from merged automatic-retry coordination, command-journal durability, distributed retry orchestration, and broader multi-node lease-execution truth, including disabled, unscheduled, scheduled, lease-blocked, recovery-needed, and scheduler-conflicted answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDurableSharedSchedulerOrchestrationState(...), GetByManagedConnectorDurableSharedSchedulerOrchestrationCategory(...), and GetByManagedConnectorDurableSharedSchedulerOrchestrationOwnerId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that durable shared scheduler answer so bounded background retry execution no longer depends on broader multi-node lease-execution truth alone when the merged scheduler answer still reports recovery-needed or scheduler-conflicted
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, durability, orchestration, lease-execution, and scheduler story
• Cephalon.Data.Debezium now participates in that broader shared scheduler lane through the existing managed-connector runtime and command surface while targeted coverage proves scheduled, unscheduled, recovery-needed, and scheduler-conflicted posture without claiming a Debezium-only scheduler subsystem
• targeted coverage now proves the durable shared scheduler-orchestration baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-190 Phase 13 managed-connector broader multi-node lease execution baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, ENG-188, and ENG-189 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and richer cross-node idempotency hardening truth, but operators still lacked one shared answer for whether the current node should actually execute the next bounded retry step once those earlier lease, hardening, and orchestration answers were all merged together
• the next follow-through needed to keep broader multi-node lease-execution posture additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only lease-execution registry, second coordinator, or second scheduler lane
• teams also needed one shared lease-execution answer that joined coordination-owner truth, active-reporter identity, scheduler metadata, retry fingerprint, and latest automatic-attempt evidence so later durable shared scheduler orchestration can build on truthful multi-node execution posture instead of re-deriving those rules in another layer

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector broader multi-node lease-execution contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, single-node, lease-executable, lease-blocked, lease-conflicted, and stale-lease-risk posture together with lease-execution categories, source truth, coordination-owner and active-reporter identity, scheduler identity, polling cadence, retry fingerprint, latest automatic-attempt evidence, and CanExecuteAutomaticRetryOnCurrentNode
• the shared execution-runtime catalog now exposes additive broader multi-node lease-execution state, category, and owner filters while deriving that posture from the same shared automatic-retry coordination, distributed-retry lease, cross-node-idempotency-hardening, and distributed-retry orchestration truth instead of forcing hosts or providers to invent another lease-execution planner
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that broader shared lease-execution answer so execution no longer trusts distributed retry orchestration alone when the merged lease or cross-node hardening evidence still says the current node should remain blocked
• ASP.NET Core publishes those same broader multi-node lease-execution filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down, and the lease-execution answer stays additive beside the existing coordination, lease, hardening, and orchestration surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later durable shared scheduler orchestration or broader Kafka Connect control-plane ownership remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionSources, and CdcCaptureExecutionRuntimeManagedConnectorMultiNodeLeaseExecutionStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorMultiNodeLeaseExecution
• Cephalon.Data now derives managed-connector broader multi-node lease-execution posture from merged automatic-retry coordination, distributed retry lease, cross-node idempotency hardening, and distributed retry orchestration truth, including operator-only, single-node, lease-executable, lease-blocked, lease-conflicted, and stale-lease-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorMultiNodeLeaseExecutionState(...), GetByManagedConnectorMultiNodeLeaseExecutionCategory(...), and GetByManagedConnectorMultiNodeLeaseExecutionOwnerId(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that broader shared lease-execution answer so bounded background retry execution no longer depends on distributed retry orchestration alone when the merged lease-execution answer still blocks the current node
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared coordination, lease, hardening, orchestration, and lease-execution story
• Cephalon.Data.Debezium now participates in that broader shared lease-execution lane through the existing managed-connector runtime and command surface while targeted coverage proves lease-executable, lease-blocked, and stale-lease-risk posture without claiming a Debezium-only lease-execution subsystem
• targeted coverage now proves the broader multi-node lease-execution baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-189 Phase 13 managed-connector richer cross-node idempotency hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, ENG-187, and ENG-188 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and distributed retry orchestration truth, but operators still lacked one shared answer for whether raw lease truth and retained command lineage were actually safe enough to schedule the next retry across nodes
• the next follow-through needed to keep cross-node idempotency hardening additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only idempotency registry, second coordinator, or second retry journal
• teams also needed one shared hardening answer that joined reporter ownership, retained lineage, retry fingerprints, automatic-attempt evidence, and durable-history posture so later broader multi-node lease execution or durable shared scheduler work can build on truthful cross-node safety evidence

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector cross-node idempotency-hardening contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, operator-only, idempotent-safe, stale-owner-risk, duplicate-lineage-risk, and replay-window-risk posture together with hardening categories, source truth, coordination-owner and active-reporter identity, retry and command fingerprints, retained-lineage evidence, automatic-attempt evidence, durable-history truth, and CanExecuteAutomaticRetryOnCurrentNode
• the shared execution-runtime catalog now exposes additive cross-node-idempotency-hardening state, category, owner, and retry-fingerprint filters while deriving that posture from the same shared automatic-retry, coordination, retry-policy, command-journal, command-journal-durability, distributed-retry-lease, and retained command-history truth instead of forcing hosts or providers to invent a second idempotency index
• the shared data pack now feeds ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through that richer shared hardening answer so distributed retry orchestration no longer trusts raw lease truth alone when retained lineage or replay evidence still looks unsafe
• ASP.NET Core publishes those same cross-node-idempotency-hardening filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down, and the hardening answer stays additive beside the existing lease, journal, durability, automatic-retry, coordination, and orchestration surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later broader multi-node lease execution, durable shared scheduler orchestration, or broader Kafka Connect control-plane ownership remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningStates, CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningCategories, CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningSources, and CdcCaptureExecutionRuntimeManagedConnectorCrossNodeIdempotencyHardeningStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCrossNodeIdempotencyHardening
• Cephalon.Data now derives managed-connector richer cross-node idempotency hardening posture from merged automatic-retry execution, automatic-retry coordination, retry-execution policy, command-journal, command-journal durability, distributed retry lease, and retained command history truth, including operator-only, idempotent-safe, stale-owner-risk, duplicate-lineage-risk, and replay-window-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCrossNodeIdempotencyHardeningState(...), GetByManagedConnectorCrossNodeIdempotencyHardeningCategory(...), GetByManagedConnectorCrossNodeIdempotencyHardeningOwnerId(...), and GetByManagedConnectorCrossNodeIdempotencyHardeningRetryFingerprint(...)
• Cephalon.Data now also feeds ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor back through that richer shared hardening answer when deriving distributed retry orchestration, so bounded background retry scheduling no longer depends on raw lease posture alone
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared automatic-retry, coordination, durability, lease, and orchestration story
• Cephalon.Data.Debezium now participates in that richer shared hardening lane through the existing managed-connector runtime and command surface while targeted coverage proves idempotent-safe, stale-owner-risk, and replay-window-risk posture without claiming a Debezium-only idempotency subsystem
• targeted coverage now proves the richer cross-node idempotency hardening baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-188 Phase 13 managed-connector distributed retry orchestration baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, ENG-186, and ENG-187 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and distributed retry lease truth, but operators still lacked one shared answer for whether the bounded automatic retry lane should actually schedule the next retry on the current node
• the next follow-through needed to keep distributed retry orchestration posture additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only scheduler lane, second coordinator, or second retry registry
• teams also needed one shared orchestration answer that joined scheduler identity, polling cadence, cooldown windows, durable-history evidence, lease safety, and latest automatic-attempt context so later durable scheduler work can build on truthful runtime orchestration posture

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector distributed retry orchestration contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, disabled, operator-only, cooldown, blocked, scheduled, and completed posture together with orchestration categories, source truth, scheduler id/kind, polling interval, owner and reporter identity, retry fingerprint, cooldown windows, latest attempt metadata, durable-history evidence, and CanScheduleAutomaticRetryOnCurrentNode
• the shared execution-runtime catalog now exposes additive distributed-retry-orchestration state, category, and owner filters while deriving that posture from the same shared automatic-retry, coordination, retry-policy, command-journal-durability, and distributed-retry-lease truth instead of forcing hosts or providers to invent a second scheduler index
• the shared data pack now gates ManagedConnectorAutomaticRetryHostedService and automatic ManagedConnectorCommandExecutor invocations through the richer distributed retry orchestration answer so bounded background retry scheduling comes from one shared runtime contract
• ASP.NET Core publishes those same distributed-retry-orchestration filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down, and the orchestration answer stays additive beside the existing lease, journal, durability, automatic-retry, and coordination surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later richer cross-node idempotency hardening, broader multi-node lease execution, durable shared scheduler orchestration, or broader Kafka Connect control-plane ownership remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationStates, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationCategories, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationSources, and CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryOrchestrationStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDistributedRetryOrchestration
• Cephalon.Data now derives managed-connector distributed retry orchestration posture from merged automatic-retry execution, automatic-retry coordination, retry-execution policy, command-journal durability, and distributed retry lease truth, including disabled, operator-only, cooldown, blocked, scheduled, and completed answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDistributedRetryOrchestrationState(...), GetByManagedConnectorDistributedRetryOrchestrationCategory(...), and GetByManagedConnectorDistributedRetryOrchestrationOwnerId(...)
• Cephalon.Data now also gates ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that richer shared answer so bounded background retry scheduling no longer depends on scattered raw lease checks
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared automatic-retry, coordination, durability, and lease story
• Cephalon.Data.Debezium now participates in that shared distributed retry orchestration lane through the existing managed-connector runtime and command surface while targeted coverage proves both scheduled, cooldown, and blocked posture without claiming a Debezium-only scheduler or second retry subsystem
• targeted coverage now proves the distributed retry orchestration baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-187 Phase 13 managed-connector distributed retry lease / cross-node idempotency hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, ENG-185, and ENG-186 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and durable command-journal truth, but operators still lacked one shared answer for whether a multi-node automatic retry lane was both lease-owned and cross-node idempotent-safe
• the next follow-through needed to keep distributed retry lease posture additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only multi-node retry coordinator, retry registry, or second command lane
• teams also needed one shared truth that joined coordination-owner identity, active reporter lease, durable journal health, retained retry fingerprint history, and duplicate automatic-attempt evidence so later distributed retry orchestration can build on restart-safe facts instead of assuming every lease-held runtime is automatically safe to execute

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector distributed retry lease contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, single-node, lease-held, lease-missing, lease-conflicted, idempotent-safe, idempotency-risk, and operator-only posture together with lease categories, source truth, coordination-owner and active-reporter identity, retry fingerprint and attempt metadata, retained-history counts, and durable journal evidence
• the shared execution-runtime catalog now exposes additive distributed-retry-lease state, category, and owner filters while deriving that posture from the same shared automatic-retry, coordination, retry-policy, command-journal, and durable-journal truth instead of forcing hosts or providers to invent a second multi-node retry index
• the shared data pack now gates ManagedConnectorAutomaticRetryHostedService and automatic command execution through the richer distributed retry lease answer so cross-node idempotency risk can block automatic retry even when raw coordination still says lease-held
• ASP.NET Core publishes those same distributed-retry-lease filters on the existing /engine/cdc-capture-runtimes* route family, including per-runtime drill-down, and the lease answer stays additive beside the existing command-journal, durability, automatic-retry, and coordination surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later durable distributed retry orchestration, richer cross-node idempotency hardening, or broader multi-node lease execution remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseStates, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseCategories, CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseSources, and CdcCaptureExecutionRuntimeManagedConnectorDistributedRetryLeaseStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDistributedRetryLease
• Cephalon.Data now derives managed-connector distributed retry lease posture from merged automatic-retry coordination, automatic-retry execution, retry-execution policy, bounded command-journal, durable journal, and retained command history truth, including single-node, lease-held, lease-missing, lease-conflicted, idempotent-safe, and idempotency-risk answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDistributedRetryLeaseState(...), GetByManagedConnectorDistributedRetryLeaseCategory(...), and GetByManagedConnectorDistributedRetryLeaseOwnerId(...)
• Cephalon.Data now also gates ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor through that richer shared answer so in-memory-only or duplicate-attempt multi-node retry evidence cannot claim current-node executability just because raw coordination remains lease-held
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared automatic-retry, coordination, journal, and durability story
• Cephalon.Data.Debezium now participates in that shared distributed retry lease lane through the existing managed-connector runtime and command surface while targeted coverage proves both idempotent-safe and idempotency-risk posture without claiming a Debezium-only retry coordinator or distributed scheduler
• targeted coverage now proves the distributed retry lease baseline through composition tests 42/42, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-186 Phase 13 managed-connector durable retry journal baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, ENG-184, and ENG-185 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and automatic background retry coordination truth, but operators still lacked one shared answer for whether retained retry evidence would survive host restart
• the next follow-through needed to keep durable journal posture additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only persistence subsystem, second journal registry, or durable distributed scheduler
• teams also needed one host-level persistence policy plus truthful recovered-versus-in-memory-only posture so later distributed retry or cross-node idempotency work can build on persisted shared evidence instead of assuming bounded in-memory history is restart-safe

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector command-journal durability contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, in-memory-only, persisted, recovered, recovery-failed, and persistence-failed posture together with durability categories, source truth, persistence path, persisted-versus-recovered timestamps, retained-versus-recorded history counts, and persisted or recovered history flags
• the shared execution-runtime catalog now exposes additive command-journal-durability-state and command-journal-durability-category methods while deriving durability posture from the same shared command-journal, automatic-retry, and coordination lane plus bounded history-store truth instead of forcing hosts or providers to invent a second journal index
• the shared data pack now exposes host-level persistence through ManagedConnectorCommandJournalPersistencePath, and ManagedConnectorCommandExecutionHistoryStore persists plus recovers bounded retry evidence without changing the existing bounded journal contract or inventing a durable distributed scheduler
• ASP.NET Core publishes those same command-journal-durability filters on the existing /engine/cdc-capture-runtimes* route family, and the durability answer stays additive beside the existing command-journal, automatic-retry, coordination, and command-execution-history surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later durable distributed retry orchestration, richer cross-node idempotency hardening, or durable shared scheduler orchestration remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityStates, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilitySources, and CdcCaptureExecutionRuntimeManagedConnectorCommandJournalDurabilityStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandJournalDurability
• Cephalon.Data now derives managed-connector command-journal durability from merged command-journal, automatic-retry execution, automatic-retry coordination, and bounded history-store truth, including in-memory-only, persisted, recovered, recovery-failed, and persistence-failed answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandJournalDurabilityState(...) and GetByManagedConnectorCommandJournalDurabilityCategory(...)
• Cephalon.Data now also exposes the host-level ManagedConnectorCommandJournalPersistencePath option, and ManagedConnectorCommandExecutionHistoryStore now persists bounded retry evidence to a shared file-backed journal and recovers that evidence across host restart so later retry flows can distinguish in-memory-only versus recovered truth
• Cephalon.AspNetCore now maps /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 so host routes stay aligned with the same shared command-journal, automatic-retry, and coordination story
• Cephalon.Data.Debezium now participates in that shared durable journal lane through the existing managed-connector runtime and command surface while targeted coverage proves persisted and recovered bounded history posture without claiming a Debezium-only persistence subsystem or durable distributed retry scheduler
• targeted coverage now proves the durable retry-journal baseline through composition tests 41/41, hosting tests 20/20, tooling tests 207/207, and the reference docs publish script

ENG-185 Phase 13 managed-connector automatic background retry coordination baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, ENG-183, and ENG-184 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and automatic background retry execution truth, but operators still lacked one shared answer for whether the current host should actually execute an eligible automatic retry or yield to another owner
• the next follow-through needed to keep automatic retry coordination additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a durable distributed scheduler, Debezium-only multi-node retry loop, or second coordination registry
• teams also needed one host-level owner identity plus truthful lease-held versus owner-mismatch versus reporter-conflict posture so bounded automatic retry would not record duplicate background attempts when reporter lease ownership and host retry ownership diverged

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector automatic background retry coordination contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, single-node, uncoordinated, lease-held, lease-missing, conflicted, and operator-only posture together with coordination categories, source truth, coordination-owner id, active-reporter id, reporter-lease timing, and CanExecuteOnCurrentNode
• the shared execution-runtime catalog now exposes additive automatic-retry-coordination-state, automatic-retry-coordination-category, and automatic-retry-coordination-owner methods while deriving coordination posture from the same shared execution ownership, execution topology, reporter coordination, automatic-retry execution, retry-execution policy, and command-journal lane instead of forcing hosts or providers to invent a second retry coordinator
• the shared data pack now exposes host-level automatic retry ownership through ManagedConnectorAutomaticRetryCoordinationOwnerId, and both the bounded ManagedConnectorAutomaticRetryHostedService and automatic invocations in ManagedConnectorCommandExecutor honor the shared CanExecuteOnCurrentNode answer instead of bypassing the shipped guardrails
• ASP.NET Core publishes those same automatic-retry-coordination filters on the existing /engine/cdc-capture-runtimes* route family, and the coordination answer stays additive beside the existing automatic-retry, retry-policy, command-journal, and command-execution-history surfaces instead of branching into a Debezium-only endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later durable distributed retry orchestration, richer cross-node idempotency hardening, durable shared retry journals, or broader provider-owned write-path orchestration remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationStates, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationCategories, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationSources, and CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryCoordinationStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorAutomaticRetryCoordination
• Cephalon.Data now derives managed-connector automatic background retry coordination from merged execution ownership, execution topology, reporter coordination, active reporter lease truth, automatic-retry execution, retry-execution policy, and command-journal posture, including single-node, lease-held, lease-missing, uncoordinated, conflicted, and operator-only answers, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorAutomaticRetryCoordinationState(...), GetByManagedConnectorAutomaticRetryCoordinationCategory(...), and GetByManagedConnectorAutomaticRetryCoordinationOwnerId(...)
• Cephalon.Data now also exposes the host-level ManagedConnectorAutomaticRetryCoordinationOwnerId option, the bounded automatic retry hosted service now runs only when ManagedConnectorAutomaticRetryCoordination.CanExecuteOnCurrentNode stays true, and the shared command executor now re-checks that same coordination truth for automatic invocations so owner-mismatch or lease-missing runtimes remain eligible-but-not-run without recording duplicate automatic attempts
• Cephalon.AspNetCore now maps /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} so host routes stay aligned with the same shared automatic-retry execution and coordination story
• Cephalon.Data.Debezium now participates in that shared automatic background retry coordination lane through the existing managed-connector execution-adapter seam while targeted coverage proves both lease-held automatic execution and owner-mismatch uncoordinated posture without claiming a durable distributed scheduler or Debezium-only retry coordinator
• targeted coverage now proves the automatic background retry coordination baseline through composition tests 40/40, hosting tests 19/19, tooling tests 207/207, and the reference docs publish script

ENG-184 Phase 13 managed-connector automatic background retry execution baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, ENG-182, and ENG-183 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and bounded command-journal truth, but operators still lacked one shared execution lane for when an eligible retry should actually run automatically instead of remaining only advisory runtime truth
• the next follow-through needed to keep automatic background retry execution additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only retry loop, durable distributed scheduler, or second coordinator
• teams also needed opt-in host policy, bounded polling, operator-versus-automatic invocation source truth, and safe reuse of matching approval or destructive-operation context from prior command history so automatic retry could stay truthful without bypassing the shipped guardrails

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector automatic background retry execution contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, disabled, blocked, eligible, and completed posture together with automatic-retry categories, intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness/preflight/dry-run/ execution-intent/execution-approval/command-envelope/command-issuance/execution-adapter/ latest-command-execution/command-retry/retry-execution-policy/command-journal state, deterministic command, retry, and execution fingerprints, latest attempt metadata, operator versus automatic invocation source, cooldown windows, and matching approval/destructive-allowance reuse flags
• the shared execution-runtime catalog now exposes additive automatic-retry-state, automatic-retry-category, and automatic-retry-operation methods while deriving automatic retry posture from the same shared retry-execution-policy, command-journal, command-retry, and command-execution history lane instead of forcing hosts or providers to invent a second retry coordinator
• the shared data pack now exposes opt-in automatic retry execution through EnableManagedConnectorAutomaticRetryExecution, ManagedConnectorAutomaticRetryPollingIntervalSeconds, and the bounded ManagedConnectorAutomaticRetryHostedService, while the shared command executor records automatic retry attempts through the same command-execution history and safety envelope instead of branching into a provider-local retry journal
• ASP.NET Core publishes those same automatic-retry filters on the existing /engine/cdc-capture-runtimes* route family, and the automatic retry answer stays additive beside the existing retry-policy, command-journal, and command-execution-history surfaces instead of branching into a Debezium-only retry endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later durable distributed retry orchestration, multi-node coordination, or broader idempotency hardening remain separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionCategories, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionOperationIds, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionSources, CdcCaptureExecutionRuntimeManagedConnectorAutomaticRetryExecutionStatus, and CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionInvocationSources, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorAutomaticRetryExecution
• Cephalon.Data now derives managed-connector automatic background retry posture from merged retry-execution-policy, command-journal, command-retry, command-execution history, execution-approval, command-envelope, command-issuance, execution-adapter, and broader runtime truth, including matching approval and destructive-allowance reuse flags, cooldown windows, operator-versus-automatic invocation-source truth, latest automatic-attempt metadata, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorAutomaticRetryExecutionState(...), GetByManagedConnectorAutomaticRetryExecutionCategory(...), and GetByManagedConnectorAutomaticRetryExecutionOperationId(...)
• Cephalon.Data now also exposes the bounded shared automatic retry lane through EnableManagedConnectorAutomaticRetryExecution, ManagedConnectorAutomaticRetryPollingIntervalSeconds, and ManagedConnectorAutomaticRetryHostedService, while the shared command executor now records automatic retry attempts through the same execution-history lane with explicit automatic-retry invocation-source truth
• Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/automatic-retries/{automaticRetryState}, /engine/cdc-capture-runtimes/automatic-retries/categories/{automaticRetryCategory}, and /engine/cdc-capture-runtimes/automatic-retries/operations/{operationId} so host routes stay aligned with the same shared retry-policy, command-journal, and bounded retry-execution story
• Cephalon.Data.Debezium now participates in that shared automatic background retry lane through the existing managed-connector execution-adapter seam while targeted coverage proves bounded restart retry flow, matching approval reuse, automatic-attempt recording, and completed automatic-retry posture without claiming a durable distributed scheduler or Debezium-only retry coordinator
• targeted coverage now proves the automatic background retry baseline through composition tests 40/40, hosting tests 18/18, tooling tests 207/207, and the reference docs publish script

ENG-183 Phase 13 managed-connector bounded command-journal hardening baseline

Status: done Estimate: 5 Completed: April 24, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, ENG-181, and ENG-182 already shipped shared coverage, remediation, governance, desired-versus-observed 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, and retry-execution-policy truth, but operators still lacked one shared answer for whether the bounded command history behind those retry and automation decisions was empty, truncated, duplicate-backed, cooling down, or still insufficient for safe automation
• the next follow-through needed to keep command-journal posture additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only durable journal, second coordinator, or premature automatic background retry loop
• teams also needed retained-versus-recorded history counts plus oldest-versus-latest retained attempt truth so shared command history could explain bounded retention and truncation semantics without rebuilding journal governance inside hosts or provider packs

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector command-journal contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, empty, bounded, truncated, cooldown-active, duplicate-evidence-present, and insufficient-for-automation posture together with journal categories, intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness/preflight/ dry-run/execution-intent/execution-approval/command-envelope/command-issuance/ execution-adapter/latest-command-execution/command-retry/retry-execution-policy state, retained-versus-recorded history counts, deterministic fingerprint matching, latest-versus-oldest retained attempt metadata, and cooldown windows
• the shared execution-runtime catalog now exposes additive command-journal-state and command-journal-category methods while deriving journal posture from the same shared command-execution history, command-retry, and retry-execution-policy lane instead of forcing hosts or providers to invent a second durable journal registry
• ASP.NET Core publishes those same command-journal filters plus a per-runtime command-journal read on the existing /engine/cdc-capture-runtimes* route family, and the journal answer stays additive beside the existing command-execution-history, command-retry, and retry-execution-policy surfaces instead of branching into a Debezium-only durable-journal endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later automatic background retry or broader idempotency hardening remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandJournalStates, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandJournalSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandJournalStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandJournal
• Cephalon.Data now derives managed-connector command-journal posture from merged command-execution history, command-retry, retry-execution-policy, command-issuance, execution-adapter, execution-approval, command-envelope, execution-intent, dry-run, preflight, write-path-readiness, governance, drift, remediation, and coverage truth, including retained versus recorded history counts, truncation posture, cooldown windows, duplicate-fingerprint evidence, latest-versus-oldest retained attempt metadata, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandJournalState(...) plus GetByManagedConnectorCommandJournalCategory(...)
• Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/command-journals/{journalState}, /engine/cdc-capture-runtimes/command-journals/categories/{journalCategory}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-journal so host routes stay aligned with the same shared command lane, retry-policy surface, and bounded-history story
• Cephalon.Data.Debezium now proves that shared command-journal baseline against the existing pause/delete/reconcile command lane by surfacing empty, bounded, truncated, cooldown-active, duplicate-evidence-present, and insufficient-for-automation truth without claiming automatic background retry, durable distributed journals, or a second Debezium command-journal registry
• targeted coverage now proves the bounded command-journal baseline through composition tests 39/39, hosting tests 17/17, tooling tests 207/207, and the reference docs publish script

ENG-182 Phase 13 managed-connector retry-execution policy baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, ENG-180, and ENG-181 already shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, execution-intent, execution-approval, command-envelope, command-issuance, provider execution-adapter, execution outcome/history, and retry/idempotency truth, but operators still lacked one shared answer for whether the engine should treat a retry as not-needed, cooled down, blocked by policy, blocked pending approval, or merely disabled because automatic background retry is not owned yet
• the next follow-through needed to keep retry-execution policy additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only retry-policy registry, second coordinator, or premature automatic retry loop
• teams also needed typed policy categories plus operation-aware drill-down so shared command history, safety posture, and execution-adapter truth could answer “should Cephalon retry this” without rebuilding retry governance inside hosts or provider packs

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector retry-execution policy contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, not-needed, cooldown, manual-approval, policy-blocked, operator-only, background-retry-disabled, and future retry-ready posture together with policy categories, intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness/preflight/dry-run/ execution-intent/execution-approval/command-envelope/command-issuance/execution-adapter/ latest-command-execution state, deterministic retry fingerprints, latest attempt metadata, and cooldown windows
• the shared execution-runtime catalog now exposes additive retry-execution-policy-state, retry-execution-policy-category, and retry-execution-policy-operation methods while deriving policy posture from the same shared command-retry, command-history, issuance, adapter, and approval lane instead of forcing hosts or providers to invent a second retry-policy registry
• ASP.NET Core publishes those same retry-execution-policy filters on the existing /engine/cdc-capture-runtimes* route family, and the policy answer stays additive beside the existing command-retry and command-execution-history surfaces instead of branching into a Debezium-only retry-policy endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later automatic background retry or durable command-journal hardening remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyStates, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyCategories, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyOperationIds, CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicySources, and CdcCaptureExecutionRuntimeManagedConnectorRetryExecutionPolicyStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorRetryExecutionPolicy
• Cephalon.Data now derives managed-connector retry-execution policy posture from merged command-retry, command-execution history, command-envelope, command-issuance, execution-adapter, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, governance, drift, remediation, and coverage truth, including policy categories, retry fingerprints, latest attempt metadata, cooldown windows, approval gating, and automatic-retry-disabled posture, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorRetryExecutionPolicyState(...), GetByManagedConnectorRetryExecutionPolicyCategory(...), and GetByManagedConnectorRetryExecutionPolicyOperationId(...)
• Cephalon.AspNetCore now maps /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} so host routes stay aligned with the same shared command lane, retry surface, and safety-policy story
• Cephalon.Data.Debezium now proves that shared retry-execution policy against the existing pause/reconcile command lane by surfacing cooldown, manual-approval, policy-blocked, and background-retry-disabled truth without claiming automatic background retry, durable command journals, or a second Debezium retry-policy registry
• targeted coverage now proves the retry-execution policy baseline through composition tests 38/38, hosting tests 16/16, tooling tests 207/207, and the reference docs publish script

ENG-181 Phase 13 managed-connector retry/idempotency hardening baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, ENG-179, and ENG-180 already shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, execution-intent, execution-approval, command-envelope, command-issuance, provider execution-adapter, and execution outcome/history truth, but operators still lacked one shared answer for whether the latest managed-connector command should be retried, blocked as a duplicate, cooled down, or kept operator-only on the same runtime surface
• the next follow-through needed to keep retry/idempotency posture additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only retry registry, second coordinator, or durable control-plane journal
• teams also needed deterministic fingerprint matching plus bounded cooldown posture so shared command history could distinguish safe retry, duplicate replay, no-op history, and still-blocked execution answers without rebuilding idempotency logic in hosts or provider packs

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector command-retry contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, not-needed, duplicate, cooldown, retry-blocked, operator-only, and retry-eligible posture together with retry categories, the intended operation id, source coverage/remediation/ governance/drift/action-plan/write-path-readiness/preflight/dry-run/execution-intent/ execution-approval/command-envelope/command-issuance/execution-adapter/latest-command-execution state, deterministic retry fingerprints, latest attempt metadata, and cooldown windows
• the shared execution-runtime catalog now exposes additive command-retry-state, command-retry-category, and command-retry-operation methods while deriving retry posture from the same shared command history, issuance, and adapter lane instead of forcing hosts or providers to invent a second retry/idempotency registry
• ASP.NET Core publishes those same command-retry filters on the existing /engine/cdc-capture-runtimes* route family, and the retry answer stays additive beside the existing command-execution history surface instead of branching into a Debezium-only retry endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later retry-execution policy or durable command-journal hardening remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandRetryStates, CdcCaptureExecutionRuntimeManagedConnectorCommandRetryCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandRetryOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandRetrySources, and CdcCaptureExecutionRuntimeManagedConnectorCommandRetryStatus, and CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandRetry
• Cephalon.Data now derives managed-connector command-retry posture from merged command history, command-envelope, command-issuance, execution-adapter, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, governance, drift, remediation, and coverage truth, including retry categories, fingerprint matching, latest attempt metadata, and bounded cooldown windows, and ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandRetryState(...), GetByManagedConnectorCommandRetryCategory(...), and GetByManagedConnectorCommandRetryOperationId(...)
• Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/command-retries/{retryState}, /engine/cdc-capture-runtimes/command-retries/categories/{retryCategory}, and /engine/cdc-capture-runtimes/command-retries/operations/{operationId} so host routes stay aligned with the same shared command lane, history surface, and retry/idempotency story
• Cephalon.Data.Debezium now proves that shared retry posture against the existing pause/delete command history by surfacing cooldown, duplicate, no-op, and operator-only truth without claiming automatic background retries, durable provider completion ownership, or a second Debezium retry registry
• targeted coverage now proves the retry/idempotency hardening baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-180 Phase 13 managed-connector execution outcome/history baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, ENG-178, and ENG-179 already shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, execution-intent, execution-approval, command-envelope, command-issuance, and provider execution-adapter truth, but operators still lacked one shared answer for what the last managed connector command attempt did and whether any recent execution history existed on the same runtime surface
• the next follow-through needed to keep latest command outcome plus bounded recent history additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only execution journal, second coordinator, or separate provider control-plane registry
• teams also needed typed attempt ids, recorded timestamps, and explicit unrecorded posture so the shared command-execution lane could distinguish “no attempt yet” from blocked, no-op, adapted, or operator-only command answers without rebuilding that logic in hosts or provider packs

Acceptance:

• Cephalon.Abstractions extends the stable managed-connector command-execution contract with additive latest-outcome metadata on CdcCaptureExecutionRuntimeDescriptor plus explicit unrecorded posture, recorded-at timestamps, recorded-outcome flags, and deterministic attempt identity for shared command execution
• the shared execution-runtime catalog now exposes additive command-execution-state, command-execution-operation, and per-runtime command-execution-history methods while deriving the latest published outcome from the same shared command lane instead of forcing hosts or providers to invent a second execution-history registry
• ASP.NET Core publishes those same command-execution filters and per-runtime history reads on the existing /engine/cdc-capture-runtimes* route family, and the command-execution POST from ENG-179 now records the resulting shared outcome on that same surface instead of branching into a Debezium-only execution-history endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later retry/idempotency hardening remains separate follow-through

Delivered:

• Cephalon.Abstractions now extends CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionStates with stable Unrecorded, adds additive AttemptId, RecordedAtUtc, IsUnrecorded, and HasRecordedOutcome on CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionResult, and adds additive ManagedConnectorCommandExecution on CdcCaptureExecutionRuntimeDescriptor
• Cephalon.Data now records latest managed-connector command-execution posture plus bounded recent history through ManagedConnectorCommandExecutionHistoryStore, enriches the shared execution runtime with the latest recorded command outcome, and exposes GetByManagedConnectorCommandExecutionState(...), GetByManagedConnectorCommandExecutionOperationId(...), and GetManagedConnectorCommandExecutionHistory(...) on ICdcCaptureExecutionRuntimeCatalog
• Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/command-executions/{executionState}, /engine/cdc-capture-runtimes/command-executions/operations/{operationId}, and /engine/cdc-capture-runtimes/{executionRuntimeId}/command-executions so host routes stay aligned with the same shared command lane and latest-outcome story
• Cephalon.Data.Debezium now keeps Debezium or Kafka Connect command translation additive while the shared runtime surface records the immediate result of explicit pause/resume/restart/delete or reconcile requests, including typed attempt ids and timestamps, without claiming durable retry or full provider completion ownership
• targeted coverage now proves the execution outcome/history baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-179 Phase 13 managed-connector provider write-path execution-adapter baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, ENG-177, and ENG-178 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, execution-intent, execution-approval, command-envelope, and command-issuance truth, but operators still lacked one typed answer for whether a provider adapter was actually ready to translate the shared command on the same runtime surface
• that next follow-through needed to keep provider execution-adapter truth additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only transport registry or prematurely claiming Kafka Connect control-plane ownership
• teams also needed one additive execution request/result seam so the shared managed-connector story could start proving provider command translation without introducing a second coordinator or a new top-level API family

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector execution-adapter contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, blocked, operator-only, unavailable, and ready posture together with execution-adapter categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/ write-path-readiness/preflight/dry-run/execution-intent/execution-approval/command-envelope/ command-issuance state, adapter identity, deterministic adapter fingerprints, and provider-ready safety flags
• the shared execution-runtime catalog now derives that execution-adapter answer from merged command-issuance, command-envelope, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage truth instead of forcing hosts or providers to rebuild a second provider transport registry
• ICdcCaptureExecutionRuntimeCatalog exposes additive execution-adapter-state, execution-adapter-category, and execution-adapter-operation drill-down methods, ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family, and the shared command-execution request/result seam stays on that same surface instead of branching into a Debezium-only control-plane endpoint set
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later managed-connector execution outcome/history or retry/idempotency hardening remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterSources, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionAdapterStatus, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionStates, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionRequest, CdcCaptureExecutionRuntimeManagedConnectorCommandExecutionResult, ICdcCaptureExecutionRuntimeManagedConnectorExecutionAdapter, and ICdcCaptureExecutionRuntimeManagedConnectorCommandExecutor, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionAdapter
• Cephalon.Data now derives runtime-level not-applicable, blocked, operator-only, unavailable, and ready posture plus stable category ids such as observe-only-mode, blocking-remediation, runtime-truth-incomplete, governance-out-of-policy, control-plane-ownership-gap, change-planned, approval-ready, approval-required, destructive-operation, adapter-ready, adapter-unavailable, and no-execution-needed, together with intended operation ids such as none, reconcile, pause, resume, restart, and delete, adapter identity, deterministic command fingerprints, deterministic issuance fingerprints, deterministic adapter fingerprints, and provider-ready safety flags from merged command-issuance, command-envelope, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-plan, drift, governance, remediation, and coverage truth
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorExecutionAdapterState(...), GetByManagedConnectorExecutionAdapterCategory(...), and GetByManagedConnectorExecutionAdapterOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/execution-adapters/{executionAdapterState}, /engine/cdc-capture-runtimes/execution-adapters/categories/{executionAdapterCategory}, /engine/cdc-capture-runtimes/execution-adapters/operations/{operationId}, and additive POST /engine/cdc-capture-runtimes/{executionRuntimeId}/commands/{operationId} so host routes stay aligned with the same shared runtime story
• Cephalon.Data.Debezium now proves the first provider adapter through DebeziumManagedConnectorExecutionAdapter, which translates shared pause/resume/restart/delete intent into Debezium or Kafka Connect REST command shape and truthfully keeps reconcile blocked until a later configuration-payload lane exists
• targeted coverage now proves the provider execution-adapter baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-178 Phase 13 managed-connector command-issuance baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, ENG-176, and ENG-177 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, execution-intent, execution-approval, and command-envelope truth, but operators still lacked one typed answer for whether Cephalon could accept, reject, or later issue the shared command on the same runtime surface
• that next follow-through needed to keep connector-management command-issuance truth additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only issuance registry or prematurely claiming Kafka Connect control-plane ownership
• teams also needed route-level drill-downs for command-issuance state, command-issuance category, and intended operation without losing the underlying coverage, remediation, governance, drift, action-plan, write-path-readiness, preflight, dry-run, execution-intent, execution-approval, and command-envelope truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector command-issuance contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, blocked, operator-only, accepted, rejected, and issued posture together with command-issuance categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/ write-path-readiness/preflight/dry-run/execution-intent/execution-approval/command-envelope state, source truth, deterministic issuance fingerprints, and safety flags
• the shared execution-runtime catalog now derives that command-issuance answer from merged command-envelope, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage truth instead of forcing hosts or providers to rebuild a second issuance registry
• ICdcCaptureExecutionRuntimeCatalog exposes additive command-issuance-state, command-issuance-category, and command-issuance-operation drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later managed-connector execution work or broader provider write-path transport or execution adapter work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceStates, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandIssuanceStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandIssuance
• Cephalon.Data now derives runtime-level not-applicable, blocked, operator-only, accepted, rejected, and issued posture plus stable category ids such as observe-only-mode, blocking-remediation, runtime-truth-incomplete, governance-out-of-policy, control-plane-ownership-gap, change-planned, destructive-operation, approval-required, approval-ready, approval-gated, accepted, rejected, issued, and no-execution-needed, together with intended operation ids such as none, reconcile, pause, and delete, issuance source truth, target connector identity, deterministic command fingerprints, deterministic issuance fingerprints, and safety flags from merged command-envelope, execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-plan, drift, governance, remediation, and coverage truth
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandIssuanceState(...), GetByManagedConnectorCommandIssuanceCategory(...), and GetByManagedConnectorCommandIssuanceOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/command-issuances/{issuanceState}, /engine/cdc-capture-runtimes/command-issuances/categories/{issuanceCategory}, and /engine/cdc-capture-runtimes/command-issuances/operations/{operationId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the command-issuance baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-177 Phase 13 managed-connector write-path command-envelope baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, ENG-175, and ENG-176 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, execution-intent, and execution-approval truth, but operators still lacked one typed answer for what canonical write-path envelope Cephalon would actually carry forward on the same shared runtime surface
• that next follow-through needed to keep connector-management command-envelope truth additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only execution registry or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for command-envelope state, command-envelope category, and intended operation without losing the underlying coverage, remediation, governance, drift, action-plan, write-path-readiness, preflight, dry-run, execution-intent, and execution-approval truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector command-envelope contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, blocked, operator-only, approval-gated, and engine-ready posture together with command-envelope categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/ write-path-readiness/preflight/dry-run/execution-intent/execution-approval state, the current primary action id, source truth, target identity, deterministic command fingerprints, and safety flags
• the shared execution-runtime catalog now derives that command-envelope answer from merged execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-planning, drift, governance, remediation, and coverage truth instead of forcing hosts or providers to rebuild a second execution registry
• ICdcCaptureExecutionRuntimeCatalog exposes additive command-envelope-state, command-envelope-category, and command-envelope-operation drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later managed-connector execution work or broader write-path command issuance remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeStates, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeCategories, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeOperationIds, CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeSources, and CdcCaptureExecutionRuntimeManagedConnectorCommandEnvelopeStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorCommandEnvelope
• Cephalon.Data now derives runtime-level not-applicable, blocked, operator-only, approval-gated, and engine-ready posture plus stable category ids such as observe-only-mode, blocking-remediation, runtime-truth-incomplete, governance-out-of-policy, control-plane-ownership-gap, change-planned, destructive-operation, approval-required, approval-ready, approval-gated, engine-ready, and no-execution-needed, together with intended operation ids such as none, reconcile, pause, and delete, source truth, target connector identity, deterministic command fingerprints, and safety flags from merged execution-approval, execution-intent, dry-run, preflight, write-path-readiness, action-plan, drift, governance, remediation, and coverage truth
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorCommandEnvelopeState(...), GetByManagedConnectorCommandEnvelopeCategory(...), and GetByManagedConnectorCommandEnvelopeOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/command-envelopes/{commandState}, /engine/cdc-capture-runtimes/command-envelopes/categories/{commandCategory}, and /engine/cdc-capture-runtimes/command-envelopes/operations/{operationId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the command-envelope baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-176 Phase 13 managed-connector execution-approval and safety-gating baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, ENG-174, and ENG-175 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, dry-run, and execution-intent truth, but operators still lacked one typed answer for whether Cephalon should currently auto-block, policy-block, queue for approval, or auto-allow the intended managed-connector follow-through on the same shared runtime surface
• that next follow-through needed to keep connector-management execution approval additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only approval registry or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for execution-approval state, execution-approval category, and intended operation without losing the underlying coverage, remediation, governance, drift, action-plan, write-path-readiness, preflight, dry-run, and execution-intent truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector execution-approval contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, auto-blocked, policy-blocked, approval-required, approval-ready, and auto-eligible posture together with execution-approval categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness/preflight/dry-run/execution-intent state, the current primary action id, the safety-gating source id, and explicit-approval detail
• the shared execution-runtime catalog now derives that execution-approval answer from merged coverage, remediation, governance, drift, action-planning, write-path-readiness, preflight, dry-run, and execution-intent truth instead of forcing hosts or providers to rebuild a second approval registry
• ICdcCaptureExecutionRuntimeCatalog exposes additive execution-approval-state, execution-approval-category, and execution-approval-operation drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later managed-connector write-path command-envelope or execution work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalSources, and CdcCaptureExecutionRuntimeManagedConnectorExecutionApprovalStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionApproval
• Cephalon.Data now derives runtime-level not-applicable, auto-blocked, policy-blocked, approval-required, approval-ready, and auto-eligible posture plus stable category ids such as observe-only-mode, blocking-remediation, incomplete-reporting-coverage, runtime-truth-incomplete, governance-out-of-policy, control-plane-ownership-gap, destructive-operation, approval-required, approval-ready, auto-eligible, and no-execution-needed, together with intended operation ids such as none, reconcile, pause, and delete, from merged dry-run, execution-intent, preflight, write-path-readiness, action-plan, drift, governance, remediation, and coverage truth; destructive or drift-sensitive follow-through now surfaces as explicit approval-required truth without materializing a second safety-gating coordinator
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorExecutionApprovalState(...), GetByManagedConnectorExecutionApprovalCategory(...), and GetByManagedConnectorExecutionApprovalOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/execution-approvals/{executionApprovalState}, /engine/cdc-capture-runtimes/execution-approvals/categories/{executionApprovalCategory}, and /engine/cdc-capture-runtimes/execution-approvals/operations/{operationId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the execution-approval baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-175 Phase 13 managed-connector execution-intent baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, ENG-173, and ENG-174 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, preflight, and dry-run truth, but operators still lacked one typed answer for what Cephalon currently intends to execute next on the same shared runtime surface and whether that next step remains deferred, blocked, operator-owned, approval-gated, or ready for a future engine-execution lane
• that next follow-through needed to keep connector-management execution intent additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only execution planner or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for execution-intent state, execution-intent category, and intended operation without losing the underlying coverage, remediation, governance, drift, action-plan, write-path-readiness, preflight, and dry-run truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector execution-intent contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, deferred, blocked, operator-action, requires-approval, and ready-to-execute posture together with execution-intent categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness/preflight/dry-run state, the current primary action id, the confidence-source id, and additive potential-change detail
• the shared execution-runtime catalog now derives that execution-intent answer from merged coverage, remediation, governance, drift, action-planning, write-path-readiness, preflight, and dry-run truth instead of forcing hosts or providers to rebuild a second execution planner
• ICdcCaptureExecutionRuntimeCatalog exposes additive execution-intent-state, execution-intent-category, and execution-intent-operation drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later managed-connector execution-approval, safety-gating, or write-path command-envelope work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentStates, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentCategories, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentOperationIds, CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentSources, and CdcCaptureExecutionRuntimeManagedConnectorExecutionIntentStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorExecutionIntent
• Cephalon.Data now derives runtime-level not-applicable, deferred, blocked, operator-action, requires-approval, and ready-to-execute posture plus stable category ids such as observe-only-mode, incomplete-reporting-coverage, governance-out-of-policy, runtime-truth-incomplete, future-control-plane, operator-only, engine-execution-candidate, approval-required, no-execution-needed, change-planned, and lifecycle-change, together with intended operation ids such as none, reconcile, and pause, from merged dry-run, preflight, write-path-readiness, action-plan, drift, governance, remediation, and coverage truth; reconcile paths that would still apply control-plane changes remain operator-owned while lifecycle operations such as pause can now surface approval-gated or ready-to-execute future engine lanes without materializing a second execution planner
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorExecutionIntentState(...), GetByManagedConnectorExecutionIntentCategory(...), and GetByManagedConnectorExecutionIntentOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/execution-intents/{executionIntentState}, /engine/cdc-capture-runtimes/execution-intents/categories/{executionIntentCategory}, and /engine/cdc-capture-runtimes/execution-intents/operations/{operationId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the execution-intent baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-174 Phase 13 managed-connector dry-run baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, ENG-172, and ENG-173 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, write-path readiness, and preflight truth, but operators still lacked one typed answer for what Cephalon believes would happen if it attempted the intended managed-connector operation right now on the same shared runtime surface
• that next follow-through needed to keep connector-management dry-run additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only dry-run planner or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for dry-run state, dry-run category, and intended operation without losing the underlying coverage, remediation, governance, drift, action-plan, write-path-readiness, and preflight truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector dry-run contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, deferred, blocked, no-op, and would-change posture together with dry-run categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness/ preflight state, the current primary action id, and additive potential-change detail
• the shared execution-runtime catalog now derives that dry-run answer from merged coverage, remediation, governance, drift, action-planning, write-path-readiness, and preflight truth instead of forcing hosts or providers to rebuild a second dry-run planner
• ICdcCaptureExecutionRuntimeCatalog exposes additive dry-run-state, dry-run-category, and dry-run-operation drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management execution-intent or broader write-path execution work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDryRunStates, CdcCaptureExecutionRuntimeManagedConnectorDryRunCategories, CdcCaptureExecutionRuntimeManagedConnectorDryRunOperationIds, and CdcCaptureExecutionRuntimeManagedConnectorDryRunStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDryRun
• Cephalon.Data now derives runtime-level not-applicable, deferred, blocked, no-op, and would-change posture plus stable category ids such as blocking-remediation, runtime-remediation, incomplete-reporting-coverage, governance-out-of-policy, runtime-truth-incomplete, observe-only-mode, no-changes-required, change-planned, lifecycle-change, connect-cluster-change, connector-class-change, source-provider-change, and task-topology-change, together with intended operation ids such as none, reconcile, and pause, from merged coverage, remediation, governance, drift, action-planning, write-path-readiness, and preflight truth instead of materializing a second dry-run registry
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDryRunState(...), GetByManagedConnectorDryRunCategory(...), and GetByManagedConnectorDryRunOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/dry-runs/{dryRunState}, /engine/cdc-capture-runtimes/dry-runs/categories/{dryRunCategory}, and /engine/cdc-capture-runtimes/dry-runs/operations/{operationId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the dry-run baseline through composition tests 37/37, hosting tests 15/15, tooling tests 207/207, and the reference docs publish script

ENG-173 Phase 13 managed-connector preflight baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, ENG-171, and ENG-172 shipped shared coverage, remediation, governance, desired-versus-observed drift, action-planning, and write-path readiness truth, but operators still lacked one typed answer for which future managed-connector operation Cephalon would preflight first and whether that preflight was blocked, deferred, not ready, or ready on the same shared runtime surface
• that next follow-through needed to keep connector-management preflight additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only preflight planner or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for preflight state, preflight category, and intended operation without losing the underlying coverage, remediation, governance, drift, action-plan, and write-path-readiness truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector preflight contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, deferred, not-ready, ready, and blocked posture together with preflight categories, the intended operation id, source coverage/remediation/governance/drift/action-plan/write-path-readiness state, and the current primary action id
• the shared execution-runtime catalog now derives that preflight answer from merged coverage, remediation, governance, drift, action-planning, and write-path-readiness truth instead of forcing hosts or providers to rebuild a second preflight planner
• ICdcCaptureExecutionRuntimeCatalog exposes additive preflight-state, preflight-category, and preflight-operation drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management dry-run or broader write-path execution work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorPreflightStates, CdcCaptureExecutionRuntimeManagedConnectorPreflightCategories, CdcCaptureExecutionRuntimeManagedConnectorPreflightOperationIds, and CdcCaptureExecutionRuntimeManagedConnectorPreflightStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorPreflight
• Cephalon.Data now derives runtime-level not-applicable, deferred, not-ready, ready, and blocked posture plus stable category ids such as blocking-remediation, runtime-remediation, incomplete-reporting-coverage, governance-out-of-policy, runtime-truth-incomplete, drift-detected, observe-only-mode, reconcile-intent, and preflight-ready, together with intended operation ids such as none and reconcile, from merged coverage, remediation, governance, drift, action-planning, and write-path-readiness truth instead of materializing a second preflight registry
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorPreflightState(...), GetByManagedConnectorPreflightCategory(...), and GetByManagedConnectorPreflightOperationId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/preflight/{preflightState}, /engine/cdc-capture-runtimes/preflight/categories/{preflightCategory}, and /engine/cdc-capture-runtimes/preflight/operations/{operationId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the preflight baseline through composition tests 36/36, hosting tests 14/14, tooling tests 207/207, and the reference docs publish script

ENG-172 Phase 13 managed-connector write-path readiness baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, ENG-170, and ENG-171 shipped shared coverage, remediation, governance, desired-versus-observed drift, and action-planning truth, but operators still lacked one typed answer for whether a managed connector was actually ready for future write-path or control-plane follow-through on the same shared runtime surface
• that next follow-through needed to keep write-path readiness additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only readiness registry or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for readiness state and readiness category while still preserving the underlying coverage, remediation, governance, drift, and action-planning truth

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector write-path-readiness contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, deferred, not-ready, ready, and blocked posture together with readiness categories, source coverage/remediation/governance/drift/action-plan state, and the current primary action id
• the shared execution-runtime catalog now derives that readiness answer from merged coverage, remediation, governance, drift, and action-planning truth instead of forcing hosts or providers to rebuild a second readiness planner
• ICdcCaptureExecutionRuntimeCatalog exposes additive readiness-state and readiness-category drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management dry-run or broader write-path execution work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessStates, CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessCategories, and CdcCaptureExecutionRuntimeManagedConnectorWritePathReadinessStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorWritePathReadiness
• Cephalon.Data now derives runtime-level not-applicable, deferred, not-ready, ready, and blocked posture plus stable category ids such as blocking-remediation, runtime-remediation, incomplete-reporting-coverage, governance-out-of-policy, runtime-truth-incomplete, drift-detected, observe-only-mode, write-path-requested, and write-path-ready from merged coverage, remediation, governance, drift, and action-planning truth instead of materializing a second readiness registry
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorWritePathReadinessState(...) plus GetByManagedConnectorWritePathReadinessCategory(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/write-path-readiness/{readinessState} and /engine/cdc-capture-runtimes/write-path-readiness/categories/{readinessCategory} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the write-path-readiness baseline through composition tests 35/35, hosting tests 13/13, tooling tests 207/207, and the reference docs publish script

ENG-171 Phase 13 managed-connector action-planning baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-168, ENG-169, and ENG-170 shipped shared remediation, governance, and desired-versus-observed drift truth, but operators still had to read those three answers and manually decide what action Cephalon should recommend next on the same shared runtime surface
• that next follow-through needed to keep managed-connector action planning additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only operator planner or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for action-plan state and action id without losing the underlying remediation, governance, and drift truth that already shipped

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector action-plan contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, observe, waiting, action-required, and blocked posture together with action-plan categories, ordered action ids, and source remediation, governance, plus drift state
• the shared execution-runtime catalog now derives that action plan from merged remediation, governance, and drift truth instead of forcing hosts or providers to rebuild a second operator planner
• ICdcCaptureExecutionRuntimeCatalog exposes additive action-plan-state and action-id drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management or broader write-path readiness work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorActionPlanStates, CdcCaptureExecutionRuntimeManagedConnectorActionPlanCategories, CdcCaptureExecutionRuntimeManagedConnectorActionPlanActionIds, and CdcCaptureExecutionRuntimeManagedConnectorActionPlanStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorActionPlan
• Cephalon.Data now derives runtime-level observe, waiting, action-required, and blocked posture plus stable category ids such as blocking-remediation, runtime-remediation, governance-out-of-policy, future-control-plane-deferred, drift-baseline-incomplete, waiting-for-runtime-truth, drift-detected, and observe-only-steady-state, along with ordered action ids such as resolve-runtime-remediation, complete-governance-declaration, defer-control-plane, complete-task-baseline, wait-for-runtime-report, investigate-drift, and keep-observe-only from merged remediation, governance, and drift truth instead of materializing a second operator planner
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorActionPlanState(...) plus GetByManagedConnectorActionId(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/action-plans/{actionPlanState} and /engine/cdc-capture-runtimes/actions/{actionId} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the action-planning baseline through composition tests 34/34, hosting tests 12/12, tooling tests 207/207, and the reference docs publish script

ENG-170 Phase 13 managed-connector desired-versus-observed drift baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-169 shipped shared managed-connector governance posture, but operators still lacked one typed answer for whether the declared connector baseline actually matched the latest reported connector topology, connector identity, and task identity on the same shared runtime surface
• that next follow-through needed to keep desired-versus-observed drift additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only drift registry or prematurely claiming Kafka Connect write-path ownership
• teams also needed route-level drill-downs for drift state and drift category without turning missing task baselines or missing runtime reports into silent “healthy” answers

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector drift contract on CdcCaptureExecutionRuntimeDescriptor that can publish not-applicable, unknown, in-sync, and drifted posture together with drift categories, recommended action ids, declared-versus-reported connector identity, declared-versus-reported task identity, and reconciliation context
• the shared execution-runtime catalog now derives that drift posture from merged descriptor-plus-report metadata instead of leaving declared-versus-reported connector truth as raw metadata only
• Cephalon.Data.Debezium contributes and normalizes shared declared and reported managedConnector* identity metadata while preserving existing debezium* metadata for compatibility
• ICdcCaptureExecutionRuntimeCatalog exposes additive drift-state and drift-category drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorDriftStates, CdcCaptureExecutionRuntimeManagedConnectorDriftCategories, CdcCaptureExecutionRuntimeManagedConnectorDriftActionIds, and CdcCaptureExecutionRuntimeManagedConnectorDriftStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorDrift
• Cephalon.Data now derives runtime-level unknown, in-sync, and drifted posture plus stable category ids such as missing-task-baseline, reported-task-topology-unavailable, reported-task-identity-unavailable, task-count-mismatch, missing-declared-task-reports, unexpected-reported-tasks, connect-cluster-mismatch, connector-class-mismatch, and source-provider-mismatch from merged managed-connector metadata instead of materializing a second operator cache
• Cephalon.Data.Debezium now writes shared declared-versus-reported managedConnector{Declared|Reported}* identity metadata beside existing debezium* metadata, so connector cluster, connector class, source-provider, and task topology truth flow into the shared execution-runtime drift answer without dropping provider-specific compatibility metadata
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorDriftState(...) plus GetByManagedConnectorDriftCategory(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/drift/{driftState} and /engine/cdc-capture-runtimes/drift/categories/{driftCategory} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the drift baseline through composition tests 33/33, hosting tests 11/11, tooling tests 207/207, and the reference docs publish script

ENG-169 Phase 13 managed-connector governance baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-165 shipped observe-only Debezium lifecycle and reconciliation truth, while ENG-168 shipped shared execution-runtime remediation posture, but operators still lacked one shared typed answer for whether a managed connector was still deliberately observe-only, already declaring future control-plane intent, or simply out of policy because governance metadata was incomplete
• that next follow-through needed to keep managed-connector governance additive on the existing /engine/cdc-capture-runtimes*, /engine/runtime-story, and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a Debezium-only governance registry or premature Kafka Connect control-plane
• teams also needed route-level drill-downs for governance state and category without claiming that Cephalon already owns create, update, pause, restart, or reconcile write paths for Kafka Connect

Acceptance:

• Cephalon.Abstractions ships a stable managed-connector governance contract on CdcCaptureExecutionRuntimeDescriptor that can publish observe-only, future-control-plane, and out-of-policy posture together with governance categories, recommended action ids, declared-versus-reported task identity, and lifecycle context
• the shared execution-runtime catalog now derives that governance posture from merged descriptor-plus-report metadata instead of leaving Debezium lifecycle truth as raw metadata only
• Cephalon.Data.Debezium contributes and normalizes shared managedConnector* metadata while preserving existing debezium* metadata for compatibility
• ICdcCaptureExecutionRuntimeCatalog exposes additive governance-state and governance-category drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeManagedConnectorGovernanceStates, CdcCaptureExecutionRuntimeManagedConnectorGovernanceCategories, CdcCaptureExecutionRuntimeManagedConnectorGovernanceActionIds, and CdcCaptureExecutionRuntimeManagedConnectorGovernanceStatus, while CdcCaptureExecutionRuntimeDescriptor now carries additive ManagedConnectorGovernance
• Cephalon.Data now derives runtime-level observe-only, future-control-plane, and out-of-policy governance posture plus stable category ids such as missing-management-mode, missing-connect-cluster-id, missing-connector-class, missing-source-provider-id, and future-control-plane-mode from merged managed-connector metadata instead of materializing a second operator cache
• Cephalon.Data.Debezium now writes shared managedConnector* metadata beside existing debezium* metadata, so declared-versus-reported task ids, expected-versus-reported task counts, lifecycle state, and reconciliation detail flow into the shared execution-runtime governance answer without dropping provider-specific compatibility metadata
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByManagedConnectorGovernanceState(...) plus GetByManagedConnectorGovernanceCategory(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/governance/{governanceState} and /engine/cdc-capture-runtimes/governance/categories/{governanceCategory} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the governance baseline through composition tests 32/32, hosting tests 10/10, tooling tests 207/207, and the reference docs publish script

ENG-168 Phase 13 external-runtime remediation summaries and drill-downs

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-167 made declared-versus-reported coverage truthful on the shared external CDC execution-runtime surface, but operators still had to manually combine coverage, stale observation, failed capture, and degraded reporter-coordination signals to decide whether one runtime actually needed remediation
• execution-runtime coverage truth could also still drift when capture ownership resolved through authored ExecutionBinding intent instead of the raw authored CdcCaptureExecutionRuntimeOptions.CdcCaptureIds list
• the next shared follow-through needed to keep one additive remediation answer on the existing /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes surfaces instead of inventing a second remediation registry or a Debezium-only operator taxonomy

Acceptance:

• Cephalon.Abstractions ships a stable execution-runtime remediation contract that can publish ready, attention, and blocked posture together with active remediation categories and affected capture ids on CdcCaptureExecutionRuntimeSummary
• the shared execution-runtime catalog now derives coverage and remediation from resolved runtime capture ownership plus current runtime-state truth instead of only the raw authored runtime descriptor ids
• ICdcCaptureExecutionRuntimeCatalog exposes additive remediation-state and remediation-category drill-down methods, and ASP.NET Core publishes those same filters on the existing /engine/cdc-capture-runtimes* route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium connector-management work remains separate follow-through

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionRuntimeRemediationStates, CdcCaptureExecutionRuntimeRemediationCategories, and CdcCaptureExecutionRuntimeRemediationStatus, while CdcCaptureExecutionRuntimeSummary now carries additive Remediation plus derived RequiresRemediation / HasBlockingRemediation helpers
• Cephalon.Data now derives execution-runtime ReportingCoverage and Remediation from resolved runtime capture ownership, keeps active remediation categories such as failed-cdc-captures, reporter-coordination-issues, stale-observations, and unreported-cdc-captures explicit, and publishes affected capture ids back onto the same shared execution-runtime summary instead of materializing a second operator cache
• ICdcCaptureExecutionRuntimeCatalog now exposes GetByRemediationState(...) plus GetByRemediationCategory(...), while Cephalon.AspNetCore now maps /engine/cdc-capture-runtimes/remediation/{remediationState} and /engine/cdc-capture-runtimes/remediation/categories/{remediationCategory} so host routes stay aligned with the same shared runtime story
• targeted coverage now proves the remediation baseline through composition tests 30/30, hosting tests 16/16, tooling tests 207/207, and the reference docs publish script

ENG-167 Phase 13 broader external-runtime reporting-coverage hardening

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-166 made the shared external CDC runtime story easier to read at the coordination-rollup level, but execution-runtime summaries could still treat descriptor-backed placeholder state as if a declared capture had already reported runtime truth
• operators still had to diff declared capture ownership against the raw runtime-state set by hand to answer whether one external runtime had reported every declared capture, especially when one runtime owned more than one capture
• the next shared follow-through needed to keep declared-versus-reported coverage additive over /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes instead of inventing a second external-runtime coverage registry or overloading reporter-coordination semantics

Acceptance:

• Cephalon.Abstractions ships a stable execution-runtime reporting-coverage contract that can publish not-bound, unreported, partially-reported, and fully-reported posture together with declared and reported counts plus the still-unreported capture ids
• CdcCaptureExecutionRuntimeSummary can now expose that additive reporting-coverage answer on the same shared execution-runtime surface while also keeping derived helper booleans for has-unreported and full-coverage posture
• the shared execution-runtime catalog now derives ReportedCdcCaptureIds and reporting-coverage truth only from captures that have submitted real observations instead of descriptor-backed placeholder state
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader external-runtime hardening remains separate work

Delivered:

• the 2026-04-23 ENG-167 slice added CdcCaptureExecutionRuntimeReportingCoverageStates plus CdcCaptureExecutionRuntimeReportingCoverageStatus to Cephalon.Abstractions, and CdcCaptureExecutionRuntimeSummary now carries additive ReportingCoverage beside the existing reporter-coordination answer
• Cephalon.Data now derives ReportedCdcCaptureIds and reporting-coverage posture only from captures whose runtime state has actual reports, so one declared external runtime can truthfully answer unreported, partially-reported, or fully-reported instead of looking complete as soon as placeholder runtime state is projected
• the same shared /engine/cdc-capture-runtimes* routes and snapshot.CdcCaptureExecutionRuntimes answers now project declared-versus-reported coverage counts plus missing capture ids directly, so operators no longer have to diff declared capture ownership against one runtime-state set by hand
• targeted coverage now proves the broader external-runtime reporting-coverage slice through composition tests 28/28, hosting tests 4/4, tooling tests 207/207, and the reference docs publish script

ENG-166 Phase 13 richer CDC operator-story rollups

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-163 made the shared external CDC runtime story queryable by reporter, edge node, coordination state, and degraded reason, but execution-runtime summaries still mostly surfaced the latest linked ReporterCoordination answer instead of one aggregate operator rollup
• operators still had to reopen multiple per-capture runtime payloads and mentally union active, standby, rejected, and degraded posture when one external runtime owned more than one capture
• the next shared follow-through needed to keep richer operator rollups additive over /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes instead of inventing a second coordination registry or a Debezium-only summary surface

Acceptance:

• Cephalon.Abstractions ships a stable execution-runtime coordination-rollup contract that can publish grouped coordination-state and degraded-reason breakdowns together with active, standby, rejected, and degraded capture ids
• CdcCaptureExecutionRuntimeSummary can now expose that additive rollup on the same shared execution-runtime surface without replacing the existing latest ReporterCoordination answer
• the shared execution-runtime catalog now derives those rollups from the linked capture runtime-state story so provider-native and external-managed runtimes both benefit from the same operator-summary answer
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader external-runtime hardening remains separate work

Delivered:

• the 2026-04-23 ENG-166 slice added CdcCaptureExecutionRuntimeReporterCoordinationRollup plus CdcCaptureReporterCoordinationBreakdownEntry to Cephalon.Abstractions, and CdcCaptureExecutionRuntimeSummary now carries additive ReporterCoordinationRollup beside the existing latest ReporterCoordination answer
• Cephalon.Data now derives runtime-level coordination-state breakdowns, degraded-reason breakdowns, distinct active or standby or rejected reporter ids, and degraded capture ids from the linked capture runtime-state catalog without inventing a second operator index
• the same shared /engine/cdc-capture-runtimes* routes and snapshot.CdcCaptureExecutionRuntimes answers now project runtime-level active-versus-standby-versus-rejected posture directly, so operators no longer have to re-aggregate one Debezium or external-runtime story by hand
• targeted coverage now proves the richer CDC operator-rollup slice through composition tests 27/27, hosting tests 3/3, tooling tests 207/207, and the reference docs publish script

ENG-165 Phase 13 Debezium lifecycle and reconciliation hardening

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-164 proved the Debezium managed-connector baseline on the shared CDC runtime story, but the pack still projected mostly raw connector metadata without a stable operator-facing lifecycle or task-reconciliation answer
• operators still had to inspect individual report payloads and infer whether the connector was current, paused, rebalancing, or diverged from its declared task ownership instead of reading that truth back from the existing shared /engine/cdc-* and snapshot surfaces
• the next Debezium follow-through needed to stay truthful about observe-only lifecycle posture and shared report-driven reconciliation without inventing a Debezium-only registry, hosted execution, or Kafka Connect control plane

Acceptance:

• DebeziumConnectorOptions can now declare lifecycle-management and task-expectation truth such as ManagementMode, ExpectedTaskCount, and declared task ids on the shared runtime descriptors
• Debezium runtime reports can now normalize connector or task lifecycle and reconciliation metadata into stable additive debezium* answers on the existing shared capture runtime-state surfaces
• the shared execution-runtime catalog can now project runtime-scoped Debezium reconciliation metadata back onto /engine/cdc-capture-runtimes* and snapshot.CdcCaptureExecutionRuntimes without inventing a second Debezium runtime registry
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium management or broader operator-rollup follow-through remains separate work

Delivered:

• the 2026-04-23 ENG-165 slice extended DebeziumConnectorOptions with ManagementMode plus ExpectedTaskCount, and now publishes that expectation alongside declared task ids on shared capture and execution-runtime descriptors
• Cephalon.Data.Debezium now normalizes raw report metadata such as connector state, task ids, task summaries, rebalance posture, connector generation, and worker identity into stable debeziumConnectorLifecycleState, debeziumTaskReconciliationState, debeziumReconciliationState, debeziumReconciliationReason, and additive task-detail metadata instead of leaving the operator story to raw connector payloads
• the shared CdcCaptureExecutionRuntimeCatalog now promotes runtime-scoped report metadata back onto execution-runtime descriptors, so Debezium lifecycle and reconciliation truth shows up on /engine/cdc-capture-runtimes* plus snapshot.CdcCaptureExecutionRuntimes without re-reading one capture payload manually
• targeted coverage now proves the Debezium lifecycle and reconciliation hardening slice through composition tests 1/1, hosting tests 1/1, tooling tests 207/207, and the reference docs publish script

ENG-164 Phase 13 Debezium external managed-connector CDC baseline

Status: done Estimate: 5 Completed: April 23, 2026

Why:

• ENG-155 through ENG-163 made the shared external CDC runtime story truthful for reporter failover, edge-node provenance, degraded posture, and operator drill-downs, but the repo still did not prove that story against a real external managed-connector family such as Debezium or Kafka Connect
• the phase-13 CDC line still needed one slice that projected external managed capture ownership onto the shared /engine/cdc-*, /engine/runtime-story, and snapshot surfaces without faking a hosted execution, execution graph, or Debezium-only registry
• hosts still had to remember EnableExternalCdcRuntimeReporting = true explicitly even when the active pack itself was an external managed-connector family, which kept the adoption story noisier than necessary

Acceptance:

• a Debezium companion pack contributes managed connector runtimes and capture descriptors on the shared CDC runtime surfaces without inventing a Debezium-only registry
• the Debezium pack keeps execution ownership truthful as external-managed plus managed-connector and does not fake hosted execution or execution-graph surfaces that Cephalon does not own
• hosts that already add Cephalon.Data can accept Debezium-managed runtime reports without also setting the base external-reporting flag manually
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while later Debezium lifecycle and reconciliation hardening remains separate follow-through

Delivered:

• the 2026-04-23 ENG-164 slice shipped Cephalon.Data.Debezium with DebeziumDataOptions, DebeziumConnectorOptions, DebeziumCaptureOptions, and AddDebeziumData(...)
• Debezium-managed connectors now publish shared execution-runtime descriptors with executionOwnership = external-managed, executionTopology = managed-connector, acknowledgementMode = connector-offset-commit, optional reporter-lease and stale-observation posture, declared task ids, and declared edge-node ids through the existing /engine/cdc-capture-runtimes* and snapshot surfaces
• Debezium-managed captures now publish through the existing /engine/cdc-captures* surfaces with authored capture ownership preserved, connector/runtime metadata kept additive, and metadata.contributorModuleId = "debezium-data" instead of inventing a second Debezium catalog
• the Debezium pack now auto-registers the shared ICdcCaptureExecutionRuntimeReportSink bridge whenever Debezium connectors are configured, so POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports stays available without requiring EnableExternalCdcRuntimeReporting = true explicitly on the host
• targeted coverage now proves the Debezium managed-connector baseline through composition tests 1/1, hosting tests 1/1, tooling tests 185/185, and the reference docs publish script

ENG-157 Phase 13 stronger reporter takeover and degraded-posture hardening baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-156 kept participant-level active, standby, and rejected truth visible, but the shared runtime story still needed a stable way to distinguish an expired lease awaiting takeover, a rejected conflict, and a runtime-level multiple-active ambiguity
• operators still needed the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces to answer when reporter coordination was degraded even though the raw coordination state was not always just conflicted
• stronger takeover and degraded-posture semantics still had to stay additive over the shipped shared coordination contract and external reporting seam instead of inventing a second operator taxonomy in ASP.NET Core or one provider pack

Acceptance:

• Cephalon.Abstractions extends the shared CDC reporter-coordination contract with stable takeover-state and degraded-reason identifiers plus derived helpers so capture-first and runtime-first surfaces can expose one operator-facing posture
• Cephalon.Data derives awaiting-takeover, rejected-conflict, completed-takeover, and multiple-active ambiguity answers from the shared runtime-state catalog while keeping /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot aligned on the same typed coordination story
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader external follow-through and later provider-specific capture implementations remain later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureReporterCoordinationIssueReasons plus CdcCaptureReporterTakeoverStates, while CdcCaptureReporterCoordinationStatus now carries TakeoverState, DegradedReason, RequiresTakeover, and HasCompletedTakeover
• Cephalon.Data now treats lease-expired coordination as degraded when a runtime is still awaiting failover, keeps completed takeovers non-degraded, classifies rejected conflicts through rejected-reporter-conflict, and now also surfaces runtime-level multiple-active-reporters ambiguity on both per-capture runtime-state and execution-runtime summary answers without inventing a second operator-story registry
• targeted coverage now proves rejected-conflict, multi-capture multiple-active ambiguity, lease-expiry awaiting-takeover, completed takeover, ASP.NET Core surface publication, and public package-surface truth through composition tests 24/24, hosting tests 3/3, tooling tests 181/181, and the reference docs publish script

ENG-156 Phase 13 richer multi-reporter reconciliation and operator-story hardening baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-155 added reporter failover and takeover truth, but the shared runtime story still mostly answered one active owner plus one last conflicting or previous reporter at a time
• operators still needed the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces to say which reporters were currently active, standing by after lease-expiry takeover, or explicitly rejected for lease conflicts without inventing a second coordinator or host-only projection
• richer multi-reporter reconciliation still had to stay additive over the shipped shared runtime-state, execution-runtime summary, and external reporting contracts instead of baking a separate operator-story model into ASP.NET Core or one provider pack

Acceptance:

• Cephalon.Abstractions extends the shared CDC reporter-coordination contract with participant roles and participant descriptors so per-capture and per-runtime answers can publish active, standby, and rejected reporter stories on the same typed contract
• Cephalon.Data derives participant-level coordination truth from accepted reports, expired-lease takeover memory, and rejected conflicts while keeping /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot aligned on one operator-facing answer
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while stronger takeover policy, degraded-posture hardening, and later provider-specific capture implementations remain later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureReporterParticipantRoles plus CdcCaptureReporterParticipantStatus, while CdcCaptureReporterCoordinationStatus now carries ReporterParticipants, HasStandbyReporters, and HasRejectedReporters beside the existing coordination posture
• Cephalon.Data now keeps previous active owners visible as standby participants after accepted lease-expiry takeovers, keeps rejected conflicting reporters visible as rejected participants, and derives the same participant story on both per-capture runtime state and execution-runtime summary surfaces without inventing a second reporter registry
• targeted coverage now proves rejected-conflict, lease-expiry, takeover, ASP.NET Core surface, and public package-surface truth through composition tests 23/23, hosting tests 4/4, tooling tests 181/181, and the reference docs publish script

ENG-155 Phase 13 richer external and edge-aware CDC failover and takeover baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-152 introduced reporter and edge identity plus reporter-lease enforcement, but the shared runtime story still only answered accept-or-reject behavior while active leases existed
• operators still needed the existing /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces to say whether one runtime currently had an active owner, an expired lease waiting for takeover, or a degraded conflicting reporter posture without inventing a second coordinator
• richer failover and takeover truth still had to stay additive over the shipped shared CDC descriptor, runtime-state, execution-runtime summary, and edge-aware reporting contracts instead of pushing reporter-failover logic into an HTTP-only host adapter

Acceptance:

• Cephalon.Abstractions extends the shared CDC runtime-state and execution-runtime summary contracts with first-class reporter-coordination posture that can answer active ownership, expired-lease posture, takeover history, and conflicting reporter evidence without replacing the existing reporter and edge identity fields
• Cephalon.Data records rejected conflicting reporters plus accepted reporter takeovers on the existing runtime-state catalog, derives active, lease-expired, conflicted, not-configured, and unreported coordination states from shared lease truth, and keeps /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot aligned on one operator-facing answer
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while richer multi-reporter reconciliation, stronger takeover policy, and later provider-specific capture implementations remain later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureReporterCoordinationStates plus CdcCaptureReporterCoordinationStatus, while CdcCaptureRuntimeState and CdcCaptureExecutionRuntimeSummary now expose first-class ReporterCoordination answers alongside the existing reporter and edge identity fields
• Cephalon.Data now records rejected conflicting reporters, detects lease-expiry takeovers, projects active, lease-expired, conflicted, not-configured, and unreported coordination states from the shared runtime-state catalog, and keeps those answers additive over the existing LastReporterId, ActiveReporterId, ReporterLeaseExpiresAtUtc, and ObservedEdgeNodeIds story instead of inventing a second failover registry
• targeted coverage now proves rejected-conflict truth, lease-expiry posture, reporter takeover projection, ASP.NET Core surface publication, public package-surface alignment, and the reference docs publish script through composition tests 23/23, hosting tests 4/4, tooling tests 181/181, and the reference docs publish script

ENG-154 Phase 13 PostgreSQL publication and slot lifecycle hardening baseline

Status: done Estimate: 5 Completed: April 22, 2026

Why:

• ENG-153 proved provider-native PostgreSQL logical-replication execution, but the shared runtime story still lacked truthful publication and slot lifecycle posture for invalidated slots, slot ownership mismatches, and restart-safe resume semantics
• operators still needed the shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces to answer whether a slot was ready, recreated, invalidated, lost, or blocked without inventing a PostgreSQL-only watchdog
• Postgres-specific restart and resume truth still had to stay additive over the shipped shared CDC descriptor/runtime-state/execution-runtime contracts instead of bypassing them with a provider-local monitor

Acceptance:

• Cephalon.Data.Postgres keeps the same shared CDC surfaces while classifying publication ownership, slot lifecycle state, slot lifecycle action, restart-safe resume posture, and provider-specific failure kind metadata on the existing descriptor and runtime-state contracts
• the PostgreSQL runner validates slot type, plugin, database ownership, invalidation or WAL-loss posture, and active-slot conflict semantics, and can optionally drop and recreate inactive invalidated slots when RecreateSlotIfInvalidated = true
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while broader external or edge-aware CDC follow-through and later provider-specific capture implementations remain later work

Delivered:

• PostgresLogicalReplicationCaptureOptions now exposes RecreateSlotIfInvalidated, descriptors now publish additive recreateSlotIfInvalidated, slotLifecyclePolicy, and slotResumeMode metadata, and the hosted runner now preserves those answers on the shared runtime-state surface
• PostgresLogicalReplicationTransport now validates publication/table ownership plus slot type, plugin, database, synced-standby, active-consumer, invalidated, and WAL-loss posture; it reports slotLifecycleState, slotLifecycleAction, slotResumeMode, slotRestartLsn, slotConfirmedFlushLsn, slotWalStatus, and slotInvalidationReason, and can recreate inactive invalidated slots truthfully when configured
• targeted coverage now proves the hardened PostgreSQL lifecycle story through composition tests 23/23, hosting tests 2/2, tooling tests 181/181, and the reference docs publish script

ENG-137 Phase 13 edge-runtime cell traffic materializer baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-136 proved provider-managed reconciliation on the shared traffic catalog, but edge-managed and provider-and-edge-managed routes still could not answer whether edge targeting had actually been reconciled against the active edge runtime
• Cephalon.Edge needed a pack-owned materializer seam that could plug into the shared automation catalog without making Cephalon.Engine depend directly on edge-runtime implementation services
• startup reconciliation still had to stay additive and deterministic: route ownership, health-isolation linkage, and edge-targeting validation remain engine-owned, while the concrete edge materializer is selected from DI at runtime

Acceptance:

• Cephalon.Abstractions extends the shared traffic-automation contract with a host-agnostic edge materializer interface, generic materialization result/state contracts reusable by provider and edge materializers, and first-class edge-materialization fields on the shared runtime descriptor
• Cephalon.Engine selects a single edge materializer for edge-managed or provider-and-edge-managed routes, seeds pending or unavailable answers on the shared runtime catalog, and runs startup reconciliation back into that same catalog without inventing a second registry
• Cephalon.Edge contributes the first concrete edge-runtime materializer behind that abstraction when edge-native-delivery is active, validating targeted edge nodes against the active edge catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while richer multi-provider reconciliation and additional provider-specific control-plane materializers remain later work

Delivered:

• Cephalon.Abstractions now ships CellTrafficAutomationMaterializationResult, CellTrafficAutomationMaterializationStates, and ICellTrafficAutomationEdgeMaterializer; the provider-named materialization result/state types remain available as compatibility helpers over the same generic contract, and CellTrafficAutomationRuntimeDescriptor now also carries EdgeMaterializerId, EdgeMaterializationState, EdgeMaterializationObservedAtUtc, and EdgeMaterializationError
• Cephalon.Engine now keeps the shared runtime catalog DI-backed for edge materializer discovery, selects one edge materializer per automation, seeds pending or unavailable answers, and runs CellTrafficAutomationEdgeMaterializationHostedService so startup reconciliation writes the observed edge-materialization result back onto the same shared automation catalog plus technology surface
• Cephalon.Edge now registers EdgeTrafficAutomationMaterializer, reconciles edge-managed and provider-and-edge-managed routes against the active IEdgeNodeCatalog, and reports edgeAction = reconciled plus targeted-node metadata back onto the shared runtime truth instead of creating an edge-only traffic registry
• targeted coverage now proves edge materializer selection, deterministic rejection when multiple edge materializers match the same automation, hosted startup reconciliation, ASP.NET Core publication of the enriched payloads on the existing routes, and public package-surface alignment through composition tests 6/6, hosting tests 1/1, tooling tests 175/175, and the reference docs publish script

ENG-136 Phase 13 provider-managed cell traffic materializer baseline

Status: done Estimate: 5 Completed: April 21, 2026

Why:

• ENG-135 shipped provider-aware and edge-aware targeting, but the shared runtime still could not answer whether a provider-managed automation was merely configured or had actually been reconciled against a real provider control plane
• providers needed one host-agnostic reconciliation contract that could stay additive over the existing traffic-automation catalog instead of introducing a second traffic-materialization registry beside /engine/cell-traffic-automations
• build-time validation for route ownership, health-isolation linkage, and edge targeting still had to stay deterministic even while the actual materializer implementation came from DI at runtime

Acceptance:

• Cephalon.Abstractions extends the shared traffic-automation contract with a host-agnostic provider materializer interface, typed reconciliation result/state contracts, and first-class provider-materialization fields on the shared runtime descriptor
• Cephalon.Engine keeps build-time automation validation deterministic, selects provider materializers by providerId, seeds pending or unavailable answers on the shared runtime catalog, and runs startup reconciliation back into that same catalog without inventing a second registry
• ASP.NET Core keeps using the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology-surface paths while exposing the new provider-materialization truth on the existing payloads
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while edge-runtime materializers remain later work

Delivered:

• Cephalon.Abstractions now ships ICellTrafficAutomationProviderMaterializer, CellTrafficAutomationProviderMaterializationResult, and CellTrafficAutomationProviderMaterializationStates, while CellTrafficAutomationRuntimeDescriptor now also carries ProviderMaterializerId, ProviderMaterializationState, ProviderMaterializationObservedAtUtc, and ProviderMaterializationError
• Cephalon.Engine now validates cell traffic automation at build time, keeps the runtime catalog DI-backed for provider materializer discovery, selects one materializer per providerId, seeds pending or unavailable answers, and runs CellTrafficAutomationProviderMaterializationHostedService so startup reconciliation writes the observed provider-materialization result back onto the same shared automation catalog plus technology surface
• the shared runtime truth now stays singular: /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and /engine/technology-surfaces/cell-based-architecture now all project the same selected materializer id, latest reconciliation state, observed-at timestamp, failure summary, and provider-reported metadata without a second API family
• targeted coverage now proves build-time validation still fails for unknown routes and edge-node targeting without edge-native-delivery, provider-managed reconciliation succeeds when a matching materializer is registered, duplicate provider ownership fails deterministically, ASP.NET Core publishes the enriched payloads on the existing routes, and public package-surface alignment holds through composition tests 5/5, hosting tests 1/1, tooling tests 175/175, and the reference docs publish script

ENG-129 Phase 13 shared CDC acknowledgement and checkpoint-commit baseline

Status: done Estimate: 5 Completed: April 20, 2026

Why:

• ENG-128 shipped the shared in-process CDC pump, but the execution contract still had no post-stage acknowledgement seam for provider-native captures that must defer durable checkpoint advancement until outbox staging succeeds
• provider packs needed one additive staged-batch acknowledgement contract so a capture can commit replay-sensitive progress only after the shared runtime confirms that the linked outbox accepted the publications
• the shared execution/runtime-story surface still skipped the checkpoint-commit step entirely, so operators could not read one truthful answer for capture, stage, acknowledge, and report transitions

Acceptance:

• Cephalon.Abstractions exposes an additive staged-batch acknowledgement contract for CDC execution without leaking provider-specific checkpoint mechanics into the engine core
• Cephalon.Data updates the shared CDC pump so acknowledgement-capable captures are called only after linked outbox staging succeeds, acknowledgement failures stay replay-safe, and pending checkpoint/change-id metadata remains operator-visible when acknowledgement fails
• the shared execution/runtime-story contract keeps the new acknowledgement step introspectable through the existing capability, execution graph, hosted execution, and snapshot surfaces instead of inventing a second runtime registry
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while remaining explicit that concrete provider-native capture implementations and alternate CDC topologies are still later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionAcknowledgement plus ICdcCaptureAcknowledger, so an acknowledgement-capable ICdcCapture implementation can receive one staged batch with stable capture/outbox ids, staged messages, counts, change ids, checkpoints, and metadata only after the shared runtime stages the linked outbox publications successfully
• Cephalon.Data now extends CdcCaptureHostedService so the shared pump optionally acknowledges staged batches after outbox success, reports acknowledgement plus acknowledgerServiceType metadata on success, and reports failureKind = acknowledgement together with pending checkpoint/change-id metadata when durable acknowledgement fails
• Cephalon.Data now keeps the operational graph truthful through the additive acknowledge-cdc-progress node in data-cdc-capture-flow, so /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and /engine/snapshot reflect the real shared CDC loop without replacing /engine/cdc-captures*
• targeted coverage now proves no-ack baseline behavior, acknowledgement success, outbox-stage failure behavior, acknowledgement failure behavior, hosting surface publication, and package-surface alignment through composition tests 9/9, hosting tests 1/1, and tooling tests 2/2

ENG-128 Phase 13 shared CDC hosted-execution substrate baseline

Status: done Estimate: 5 Completed: April 20, 2026

Why:

• ENG-125 through ENG-127 established CDC ownership, live runtime-state, and typed freshness/lag/publication posture, but Cephalon still had no shared execution substrate for actually running active captures through the same runtime contract
• provider packs needed one bounded execution result shape and one in-process host loop that could resolve active capture implementations plus linked outboxes without inventing a second host-only registry
• /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and /engine/snapshot could not yet tell the operational story for shared CDC execution even though the per-capture descriptor and runtime-state answers were already in place

Acceptance:

• Cephalon.Abstractions extends the CDC execution contract with a bounded batch result plus stable capture/outbox ids without pulling provider-specific source semantics into the engine core
• Cephalon.Data ships an optional shared CDC hosted execution pump that resolves active ICdcCapture plus linked IOutbox implementations, stages outbox publications, and reports runtime posture through the existing shared CDC runtime-state catalog
• the shared CDC pump surfaces through the existing execution/runtime-story contract with one capability, one execution graph, one hosted execution descriptor, and matching snapshot/runtime-story truth
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while remaining explicit that provider-specific capture implementations and alternate CDC execution topologies are still later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureExecutionResult, ICdcCapture.CdcCaptureId, and IOutbox.OutboxId, and ICdcCapture.CaptureAsync() now returns one bounded batch result with produced OutboxMessage items plus checkpoint/freshness/lag/publication metadata
• Cephalon.Data now ships DataRuntimeOptions.EnableCdcExecution, DataRuntimeOptions.CdcPollingIntervalSeconds, CdcCaptureHostedService, data.cdc.execution, data-cdc-capture-flow, and data-cdc-capture-pump, and the shared pump now stages active capture results through the matching outbox while reporting started, captured, idle, and failure outcomes back into the shared CDC runtime-state catalog
• shared CDC execution is now visible through IExecutionRuntimeCatalog, IHostedExecutionRuntimeCatalog, /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and /engine/snapshot without replacing the existing /engine/cdc-captures* ownership/runtime-state surfaces
• targeted coverage now proves shared CDC execution-surface publication, in-process outbox staging/reporting, runtime-story projection, and package-surface alignment through composition tests 6/6, hosting tests 1/1, and tooling tests 1/1

ENG-127 Phase 13 CDC freshness, lag, and publication posture baseline

Status: done Estimate: 5 Completed: April 20, 2026

Why:

• ENG-126 shipped the first live CDC runtime-state baseline, but operators still could not read typed freshness, lag, or publication-posture answers without parsing ad-hoc metadata or inferring too much from raw counts
• provider packs needed one additive reporter shape for freshness windows, lag posture, pending source-change counts, and pending publication counts that kept CdcCaptureRuntimeState host-agnostic and descriptor-backed
• the linked outbox dispatch runtime was already available, but the CDC surface still lacked one normalized publication-posture answer that could reuse downstream dispatch truth without inventing a second host-only monitor

Acceptance:

• Cephalon.Abstractions exposes additive CDC runtime contracts for freshness, lag, and publication posture in a provider-friendly typed shape
• Cephalon.Data extends CdcCaptureExecutionReport plus the shared runtime-state catalog so provider/runtime reporters can project freshness windows, lag posture, and pending publication counts without regressing the shipped ENG-126 baseline
• CdcCaptureRuntimeState and snapshot.CdcCaptureStates surface the richer operator answer while preserving optional linked OutboxDispatchState
• ASP.NET Core keeps the same /engine/cdc-captures/runtime* routes and returns the richer typed runtime answer without introducing a second CDC route family
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped slice while remaining explicit that provider-specific CDC execution loops themselves are still later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureFreshnessStatus, CdcCaptureLagStatus, CdcCapturePublicationStatus, and their recommended stable state identifiers so provider packs can report freshness, lag, and publication posture through one typed host-agnostic contract
• Cephalon.Data now extends CdcCaptureExecutionReport plus CdcCaptureRuntimeStateCatalog so capture observations can carry freshness windows, lag summaries, pending source-change counts, and pending publication counts without falling back to metadata-only parsing
• Cephalon.Data now also applies a conservative linked-dispatch publication overlay so CdcCaptureRuntimeState.Publication can reflect retry/failure/in-flight/current posture from the existing outbox runtime truth when the linked dispatch path already reports it
• Cephalon.Engine now projects the richer snapshot.CdcCaptureStates answer without changing the shipped descriptor/runtime route family
• ASP.NET Core continues exposing /engine/cdc-captures/runtime*, now with typed freshness, lag, publication, and linked dispatch posture on the same runtime answer
• targeted coverage now proves richer runtime-state projection, snapshot truth, ASP.NET Core route publication, and package-surface alignment through composition tests 1/1, hosting tests 1/1, and tooling tests 1/1

ENG-126 Phase 13 CDC runtime-state and publish-state follow-through

Status: done Estimate: 5 Completed: April 20, 2026

Why:

• ENG-125 established who owns each CDC capture and which outbox it publishes through, but operators still had no shared runtime answer for what the latest capture loop observed, whether changes were being produced, or how that capture related to the linked outbox dispatch posture
• provider packs needed one additive reporter/catalog path that preserved descriptor ownership and reused existing event-dispatch truth instead of inventing a second host-only CDC monitor or publication-state registry
• /engine/snapshot and ASP.NET Core hosts could not yet surface per-capture outcome, totals, checkpoints, errors, or linked downstream publish posture from one normalized runtime contract

Acceptance:

• Cephalon.Abstractions exposes host-agnostic runtime-state contracts for active CDC captures, including optional linked outbox dispatch posture
• Cephalon.Data provides the shared reporter/catalog implementation that projects descriptor-owned captures before the first report arrives, tracks latest-plus-total capture metrics, and merges existing outbox dispatch runtime truth when available
• Cephalon.Engine projects the merged CDC runtime-state answer into snapshot.CdcCaptureStates
• ASP.NET Core hosts expose direct operator routes for the runtime-state catalog and the same id/module/provider/outbox/source/resource drill-down lenses as the descriptor catalog
• docs, reference docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped runtime-state follow-through while remaining honest that provider-native execution, lag, and freshness remain later work

Delivered:

• Cephalon.Abstractions now ships CdcCaptureRuntimeState plus ICdcCaptureRuntimeStateCatalog as the public operator-facing runtime-state contract
• Cephalon.Data now ships ICdcCaptureRuntimeReporter, CdcCaptureExecutionReport, CdcCaptureRuntimeOutcomes, and CdcCaptureRuntimeStateCatalog, with descriptor-backed projection, latest-plus-total capture counters, checkpoint/change-id/error tracking, and optional linked OutboxDispatchState
• Cephalon.Engine now projects snapshot.CdcCaptureStates so merged runtime introspection can carry live CDC posture beside static capture descriptors and event-dispatch state
• ASP.NET Core now exposes /engine/cdc-captures/runtime* so operators can inspect the same runtime-state truth directly over HTTP without inventing a host-only CDC monitor
• targeted coverage now proves runtime-state projection, snapshot truth, ASP.NET Core route publication, and package-surface alignment through composition tests 1/1, hosting tests 1/1, and tooling tests 1/1
• architecture, component docs, operations guidance, roadmap, project memory, and reference docs now describe the shipped runtime-state follow-through truthfully while keeping provider-native execution, lag, and freshness explicitly later

ENG-122 Phase 13 cell-health-isolation runtime baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• ENG-120 and ENG-121 established who owns each cell boundary and how cells route to one another, but Cephalon still had no host-agnostic contract for how a cell should isolate dependency failures, readiness posture, or restart boundaries without inventing host-only health wiring
• phase 13 still needed one more engine-owned truth before configuration-driven/provider-aware traffic automation could stay honest: one shared runtime catalog for source module, cell, failure-isolation mode, readiness scope, restart scope, and dependency linkage
• the operator story was still incomplete because /engine/snapshot and /engine/technology-surfaces/cell-based-architecture could not yet show health-isolation posture over the shipped boundary and route graph

Acceptance:

• Cephalon.Abstractions exposes host-agnostic contribution and read contracts for explicit cell health-isolation answers
• Cephalon.Engine composes host-added and module-contributed cell health-isolation answers into one runtime catalog, validates isolation ownership against active module-owned cell boundaries, projects the same answer into snapshot.CellHealthIsolations, and surfaces the same posture through the technology runtime catalog without inventing a second registry
• active cell health-isolation answers keep the built-in cell-based-architecture profile truthful so operator tooling can read one runtime answer for topology, routing, and health posture without extra host ceremony
• ASP.NET Core hosts expose direct operator routes for the merged cell health-isolation catalog and its isolation/module/cell/dependency drill-down answers
• docs, backlog, roadmap, project memory, and GitHub tracking stayed aligned with the shipped baseline while the then-open configuration-driven traffic automation, data mesh, and CDC follow-through remained separately planned

Delivered:

• Cephalon.Abstractions now ships CellHealthIsolationDescriptor, ICellHealthIsolationContributor, ICellHealthIsolationRegistry, and ICellHealthIsolationCatalog so modules, hosts, and tooling can talk about explicit cell health-isolation posture without referencing Cephalon.Engine concrete types
• Cephalon.Engine now supports engine.AddCellHealthIsolation(...) plus module-owned ICellHealthIsolationContributor inputs, validates source-module ownership against the active cell graph, composes one ICellHealthIsolationCatalog, projects snapshot.CellHealthIsolations, and publishes the same answer through the cell-health-isolations technology runtime surface
• Cephalon.AspNetCore now exposes /engine/cell-health-isolations, /engine/cell-health-isolations/{healthIsolationId}, /engine/cell-health-isolations/modules/{moduleId}, /engine/cell-health-isolations/cells/{cellId}, and /engine/cell-health-isolations/dependencies/{dependencyId} as the direct operator routes for the merged cell health-isolation catalog
• targeted coverage now proves catalog composition, invalid-cell rejection, technology-surface projection, runtime-snapshot projection, ASP.NET Core route publication, and public package-surface alignment through composition tests 2/2, hosting tests 1/1, and tooling tests 168/168

ENG-121 Phase 13 cell-route runtime governance baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• ENG-120 established who owns each cell boundary, but Cephalon still had no host-agnostic contract for which module could route from one cell to another, what governance posture applied to that path, or how operators could inspect route ownership without inventing a host-only traffic registry
• phase 13 needed the next engine-owned answer before health isolation or provider-aware traffic automation could stay truthful: one shared runtime catalog for source module, source cell, target cell, routing strategy, governance mode, and transport posture
• the app-model and operator story were still incomplete because /engine/snapshot and /engine/technology-surfaces/cell-based-architecture could not yet show governed cell-to-cell flow over the shipped boundary graph

Acceptance:

• Cephalon.Abstractions exposes host-agnostic contribution and read contracts for explicit governed cell routes
• Cephalon.Engine composes host-added and module-contributed cell routes into one runtime catalog, validates route ownership against active module-owned cell boundaries, projects the same answer into snapshot.CellRoutes, and surfaces the same posture through the technology runtime catalog without inventing a second registry
• active cell routes keep the built-in cell-based-architecture profile truthful so operator tooling can read one runtime answer for topology plus route posture without extra host ceremony
• ASP.NET Core hosts expose direct operator routes for the merged cell-route catalog and its route/module/source-cell/target-cell drill-down answers
• docs, backlog, roadmap, project memory, and GitHub tracking stayed aligned with the shipped baseline while the then-open health-isolation, traffic-automation, data mesh, and CDC follow-through remained separately planned

Delivered:

• Cephalon.Abstractions now ships CellRouteDescriptor, ICellRouteContributor, ICellRouteRegistry, and ICellRouteCatalog so modules, hosts, and tooling can talk about explicit governed cell routes without referencing Cephalon.Engine concrete types
• Cephalon.Engine now supports engine.AddCellRoute(...) plus module-owned ICellRouteContributor inputs, validates source-module ownership against the active cell graph, composes one ICellRouteCatalog, projects snapshot.CellRoutes, and publishes the same answer through the cell-routes technology runtime surface
• Cephalon.AspNetCore now exposes /engine/cell-routes, /engine/cell-routes/{routeId}, /engine/cell-routes/modules/{moduleId}, /engine/cell-routes/source-cells/{cellId}, and /engine/cell-routes/target-cells/{cellId} as the direct operator routes for the merged cell-route catalog
• targeted coverage now proves catalog composition, invalid-target rejection, technology-surface projection, runtime-snapshot projection, ASP.NET Core route publication, and public package-surface alignment through composition tests 2/2, hosting tests 1/1, and tooling tests 167/167

ENG-119 Phase 12 strangler-fig ingress runtime follow-through

Status: done Estimate: 4 Completed: April 19, 2026

Why:

• after ENG-102, Cephalon could explain authored route ownership, effective target-selection, and ASP.NET Core cutover handling, but the runtime still lacked one engine-owned ingress answer for pass-through, local rewrite, absolute-endpoint, or opaque-target materialization
• teams migrating onto Cephalon need normalized ingress truth to stay host-agnostic so future hosts, companion packs, and edge adapters can observe the same route ownership without reverse-engineering ASP.NET Core middleware choices
• the operator story was still incomplete because /engine/snapshot and ASP.NET Core hosts could not yet publish one merged ingress catalog or keep host cutover explicitly derived from that shared ingress truth

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic strangler-fig ingress runtime catalog plus a typed runtime descriptor for normalized ingress materialization answers
• Cephalon.Engine derives the ingress runtime from the authored and migration-policy truth, validates projection into /engine/snapshot, and keeps cutover-adjacent answers deterministic without inventing a second registry
• ASP.NET Core hosts expose direct operator routes for the ingress view and derive cutover handling from that shared ingress truth instead of recomputing target materialization ad hoc
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped ingress scope while remaining honest that provider-specific ingress or edge automation is still later work

Delivered:

• Cephalon.Abstractions now ships IStranglerFigIngressRuntimeCatalog plus StranglerFigIngressRuntimeDescriptor so hosts, tooling, and companion packs can read normalized pass-through, local rewrite, absolute-endpoint, and opaque-target ingress answers without referencing Cephalon.Engine concrete types
• Cephalon.Engine now derives that shared ingress runtime in StranglerFigRuntimeCatalogSnapshot, projects snapshot.StranglerFigIngressRoutes, and keeps the authored route catalog plus migration-policy catalog as the underlying truth
• Cephalon.AspNetCore now exposes /engine/strangler-fig/ingress, /engine/strangler-fig/ingress/{routeId}, and /engine/strangler-fig/ingress/modules/{moduleId} while the host cutover catalog now derives from IStranglerFigIngressRuntimeCatalog
• targeted coverage now proves ingress classification, snapshot projection, runtime-route publication, and cutover derivation through composition tests 5/5, hosting tests 6/6, tooling tests 171/171, and the regenerated reference-doc publish baseline
• architecture recommendations, component docs, roadmap, backlog, and project memory now describe the shipped ingress follow-through truthfully while keeping provider-specific ingress or edge automation explicitly planned

ENG-103 Phase 12 backend-for-frontend client-binding runtime baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-095, Cephalon could describe backend-for-frontend in the app-model taxonomy, but the runtime still had no engine-owned answer for which client-specific surfaces were active, who owned them, or which transport each client binding used
• teams shaping one backend surface per client need configuration-driven and module-owned client-binding truth to stay inside the shared engine runtime instead of scattering per-host or per-project registries
• the operator story was still incomplete because /engine/snapshot and ASP.NET Core hosts could not yet report one merged client-binding catalog or auto-select the BFF pattern when bindings existed

Acceptance:

• host-agnostic read and contribution contracts for backend-for-frontend client bindings live in Cephalon.Abstractions
• Cephalon.Engine composes host-added, module-contributed, and configuration-driven client bindings into one runtime catalog and projects that answer into /engine/snapshot
• Engine:BackendForFrontend:Bindings supports configuration-driven client-binding contribution without creating a separate host-only runtime truth
• ASP.NET Core hosts expose direct operator routes for the merged backend-for-frontend client-binding catalog and its client/module/transport drill-down answers
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped runtime baseline while remaining honest that client-aware filtering or materialization follow-through is still later work

Delivered:

• Cephalon.Abstractions now ships BackendForFrontendBehaviorFilterDescriptor, BackendForFrontendClientBindingDescriptor, IBackendForFrontendClientBindingContributor, IBackendForFrontendClientBindingRegistry, and IBackendForFrontendRuntimeCatalog as the host-agnostic client-binding contribution and read layer
• Cephalon.Engine now binds Engine:BackendForFrontend:Bindings through typed settings, composes that configuration with host-added and module-contributed bindings, auto-selects the backend-for-frontend pattern when bindings exist, and projects the merged answer into snapshot.BackendForFrontendBindings
• ASP.NET Core now exposes /engine/backend-for-frontend, /engine/backend-for-frontend/{bindingId}, /engine/backend-for-frontend/clients/{clientId}, /engine/backend-for-frontend/modules/{moduleId}, and /engine/backend-for-frontend/transports/{transportId} as the direct operator surface over the shared runtime catalog
• targeted composition, hosting, and package-surface coverage now lock the new runtime truth through composition tests 3/3, hosting tests 1/1, and package-surface tests 1/1
• architecture recommendations, component docs, roadmap, backlog, and project memory now describe the shipped BFF runtime baseline truthfully while keeping client-aware filtering or transport-specific materialization explicitly planned

ENG-104 Phase 12 backend-for-frontend client-aware REST filtering runtime baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-103, Cephalon could describe which client bindings existed, but operators still had no direct runtime answer for which published REST endpoints were effectively visible to each client binding after behavior, capability, or tag filters were applied
• the next BFF follow-through needed to stay derived from the shared runtime truth instead of inventing a second ASP.NET Core-only registry that could drift away from the merged binding catalog or the published REST endpoint catalog
• teams need one client-aware REST runtime surface before later per-client OpenAPI or Scalar materialization can remain truthful and low-ceremony

Acceptance:

• Cephalon.Abstractions exposes runtime contracts for one client-binding-plus-published-endpoint answer without collapsing binding truth and REST truth into one type
• ASP.NET Core derives a client-aware REST runtime catalog from IBackendForFrontendRuntimeCatalog plus IRestEndpointRuntimeCatalog and projects that answer through /engine/snapshot
• ASP.NET Core hosts expose direct operator routes for the derived client-aware REST runtime plus binding/client/module/published-endpoint drill-down answers
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped runtime baseline while remaining honest that per-client documentation/materialization is still later work

Delivered:

• Cephalon.Abstractions now ships BackendForFrontendRestEndpointRuntimeDescriptor plus IBackendForFrontendRestRuntimeCatalog as the public client-aware REST runtime contract
• Cephalon.AspNetCore now derives AspNetCoreBackendForFrontendRestRuntimeCatalog from the shared BFF binding catalog plus published REST endpoint catalog instead of inventing a second source of truth, preserving binding-owner module identity while filtering by included/excluded behavior ids, capability keys, and tags
• /engine/backend-for-frontend/rest-endpoints, /engine/backend-for-frontend/rest-endpoints/bindings/{bindingId}, /engine/backend-for-frontend/rest-endpoints/clients/{clientId}, /engine/backend-for-frontend/rest-endpoints/modules/{moduleId}, /engine/backend-for-frontend/rest-endpoints/published/{restEndpointId}, and /engine/backend-for-frontend/rest-endpoints/{runtimeEndpointId} now expose the derived runtime answer directly
• /engine/snapshot now carries BackendForFrontendRestEndpoints so operator tooling can read the same client-aware REST truth without re-querying separate routes
• targeted hosting and package-surface coverage now lock the new runtime truth through hosting tests 1/1 and package-surface tests 2/2
• architecture recommendations, component docs, roadmap, backlog, and project memory now describe the shipped BFF REST filtering runtime truthfully while keeping per-client OpenAPI/Scalar materialization explicitly planned

ENG-105 Phase 12 backend-for-frontend REST document materialization baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-104, operators could inspect which published REST endpoints each client binding could see, but frontend teams still had no engine-owned answer for which OpenAPI and Scalar surfaces should actually be presented to one binding or one client
• that documentation/materialization follow-through needed to stay derived from the shared BFF binding catalog plus the published REST runtime truth instead of inventing a second ASP.NET Core-only documentation registry that could drift from the runtime catalogs
• host-level OpenApi:* configuration still needed to remain authoritative for route patterns, default document selection, and Scalar prefixes so BFF docs did not create a separate host configuration model

Acceptance:

• Cephalon.Abstractions exposes host-agnostic runtime contracts for materialized backend-for-frontend REST documents without leaking ASP.NET Core OpenAPI or Scalar types into the contract layer
• ASP.NET Core derives per-binding and per-client document descriptors from IBackendForFrontendRestRuntimeCatalog plus the configured OpenAPI publication settings and projects that answer into /engine/snapshot
• ASP.NET Core hosts expose direct operator routes for the derived document catalog plus scope-specific filtered OpenAPI JSON and Scalar surfaces aligned with the configured route pattern and Scalar prefix
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped materialization baseline while remaining honest that non-REST or broader frontend materialization is still later work

Delivered:

• Cephalon.Abstractions now ships BackendForFrontendRestDocumentRuntimeDescriptor plus IBackendForFrontendRestDocumentRuntimeCatalog as the public scope-specific BFF REST document contract
• Cephalon.AspNetCore now derives AspNetCoreBackendForFrontendRestDocumentRuntimeCatalog from the shared BFF REST runtime truth plus the host OpenAPI publication settings and uses AspNetCoreBackendForFrontendRestDocumentPublisher to filter documents from the keyed IOpenApiDocumentProvider surface instead of inventing a second source of documentation truth
• /engine/backend-for-frontend/rest-documents, /engine/backend-for-frontend/rest-documents/bindings/{bindingId}, /engine/backend-for-frontend/rest-documents/clients/{clientId}, and /engine/backend-for-frontend/rest-documents/{documentId} now expose the derived document catalog directly
• scope-specific filtered OpenAPI routes and Scalar pages now materialize under the configured OpenAPI and Scalar prefixes for both binding and client scopes, including custom route-pattern and Scalar-prefix host settings
• /engine/snapshot now carries BackendForFrontendRestDocuments so operator tooling can read the same documentation/materialization truth without re-deriving host routes
• targeted hosting and package-surface coverage now lock the new surface through hosting tests 2/2 and package-surface tests 2/2
• architecture recommendations, REST strategy docs, component docs, roadmap, backlog, and project memory now describe the shipped BFF REST document-materialization baseline truthfully while keeping non-REST or broader frontend materialization later

ENG-106 Phase 12 feature-flag runtime baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after the first strangler-fig and backend-for-frontend slices, phase 12 still had no engine-owned progressive-delivery contract even though the architecture guidance already called for feature flags
• modules and hosts still lacked a shared, host-agnostic way to declare which feature flags existed, who owned them, and which runtime-context dimensions they targeted
• operator tooling had no truthful runtime answer for the merged feature-flag catalog or a shared evaluation surface aligned with /engine/snapshot

Acceptance:

• Cephalon.Abstractions exposes host-agnostic feature-flag contracts for descriptors, targeting, contributors, runtime catalogs, evaluation context, and evaluation results
• Cephalon.Engine composes code-first, configuration-driven, and module-contributed flags into one deterministic runtime catalog plus evaluation service
• module-contributed flags preserve module ownership and fail composition when source metadata does not match the contributing module
• ASP.NET Core exposes operator routes for catalog, drill-down, and evaluation views without introducing host-only feature-flag truth
• architecture recommendations, component docs, roadmap, backlog, and project memory describe the shipped baseline truthfully while keeping provider-specific companion-pack integrations and any future capability publication explicit follow-through work

Delivered:

• Cephalon.Abstractions now exposes FeatureFlagDescriptor, FeatureFlagTargetingDescriptor, FeatureFlagEvaluationContext, FeatureFlagEvaluationResult, FeatureFlagSourceKind, IFeatureToggle, IFeatureFlagRuntimeCatalog, IFeatureFlagContributor, and IFeatureFlagRegistry
• Engine:Features:Flags, engine.AddFeatureFlag(...), engine.AddFeatureFlags(...), and module-level IFeatureFlagContributor inputs now merge into IFeatureFlagRuntimeCatalog and snapshot.FeatureFlags through deterministic duplicate-id and ownership validation
• InMemoryFeatureToggle now evaluates host-owned or module-owned flags across environment, module, behavior, capability, transport, tenant, subject, and tag targeting with exclusion-wins precedence
• FeatureFlagDescriptor.ProviderBindings, FeatureFlagProviderBindingDescriptor, FeatureFlagProviderEvaluationResult, IFeatureFlagProvider, Engine:Features:Flags:*:ProviderBindings, and engine.AddFeatureFlagProvider(...) now add the generic external-provider bridge baseline while keeping the Cephalon-owned descriptor catalog as the runtime source of truth
• Cephalon.AspNetCore now exposes /engine/features, /engine/features/enabled, /engine/features/disabled, /engine/features/modules/{moduleId}, /engine/features/{featureFlagId}, and /engine/features/{featureFlagId}/evaluate off the shared runtime truth
• the current baseline intentionally keeps feature-flag ownership in the catalog instead of advertising a separate runtime.feature-flags capability, because runtime capability provenance is still module-based

ENG-111 Phase 12 durable execution runtime catalog baseline

Status: done Estimate: 3 Completed: April 19, 2026

Why:

• after ENG-109, Cephalon could execute durable workflows through shared replay semantics, but operators still had no engine-owned answer for which durable workflows were active, who owned them, which transports exposed them, or which feature flags gated them
• /engine/snapshot still lacked a first-class durable-execution catalog even though the same runtime already projected other operator-facing execution surfaces there
• ASP.NET Core hosts still had no direct /engine/durable-executions routes, which forced tooling to infer durable workflow posture indirectly from lower-level behavior topology and capability metadata

Acceptance:

• Cephalon.Abstractions exposes host-agnostic durable runtime descriptor and catalog contracts
• the durable runtime catalog stays derived from the shared behavior catalog plus registered durable behavior types instead of introducing a second workflow registry beside ABT
• /engine/snapshot carries additive durable-execution answers when the catalog is active
• ASP.NET Core exposes list, behavior-id, module, and transport drill-down routes for active durable workflows without creating host-only truth
• docs, backlog, roadmap, project memory, reference docs, and focused composition/hosting/tooling coverage stay aligned with the shipped operator-surface scope while replay-progress and failure-posture follow-through remain later work

Delivered:

• Cephalon.Abstractions now exposes DurableExecutionRuntimeDescriptor and IDurableExecutionRuntimeCatalog as the host-agnostic durable workflow operator contract
• Cephalon.Behaviors.Patterns now derives IDurableExecutionRuntimeCatalog from IBehaviorCatalog plus IBehaviorTypeRegistry so active durable workflows preserve source module ownership, transport ids, required feature flags, typed input/state/output contracts, 200 / 202 / 204 success posture, and replay metadata from shared durable topology truth
• Cephalon.Engine now projects additive snapshot.DurableExecutions through optional service resolution so the runtime snapshot can answer durable workflow posture without forcing the pack into hosts that do not use it
• Cephalon.AspNetCore now exposes /engine/durable-executions, /engine/durable-executions/{behaviorId}, /engine/durable-executions/modules/{moduleId}, and /engine/durable-executions/transports/{transportId} as direct operator routes
• focused composition, hosting, package-surface, component-doc, roadmap, backlog, project-memory, and reference-doc coverage now lock the durable operator contract plus the new public surface

ENG-112 Phase 12 durable execution runtime state and failure-posture baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-111, Cephalon could answer which durable workflows were active, but operators still had no engine-owned answer for which durable streams were currently in progress, which stage last failed, whether continuation work was pending, or what stream version the runtime last replayed or appended
• /engine/snapshot still lacked a first-class durable-execution live-state surface even though the same runtime already projected live event-dispatch state there
• ASP.NET Core hosts still had no direct /engine/* routes for durable replay progress and failure posture, which forced tooling to infer active stream state indirectly from lower-level logs or event-store inspection

Acceptance:

• Cephalon.Abstractions exposes host-agnostic durable runtime-state read contracts
• Cephalon.Behaviors.Patterns reports per-stream durable observations from the shared durable strategy instead of introducing a host-only workflow-state registry
• /engine/snapshot carries additive durable-execution runtime state when the catalog is active
• ASP.NET Core exposes runtime list and drill-down routes for durable state by stream, behavior, module, and transport
• docs, backlog, roadmap, project memory, reference docs, and focused composition/hosting/tooling coverage stay aligned with the shipped live-state scope while timers, signals, and compensation helpers remain later work

Delivered:

• Cephalon.Abstractions now exposes DurableExecutionRuntimeState and IDurableExecutionRuntimeStateCatalog as the host-agnostic read layer for active durable stream posture
• Cephalon.Behaviors.Patterns now registers a shared durable runtime-state catalog and instruments DurableExecutionStrategy to report started, succeeded, continuation-staged, completed, and failed observations together with execution stage, replayed version, known version, appended event count, local-output posture, completion posture, operator-facing error summaries, and contextual metadata
• Cephalon.Engine now projects additive snapshot.DurableExecutionStates through optional service resolution so the runtime snapshot can answer per-stream durable posture without forcing the pattern pack into hosts that do not use it
• Cephalon.AspNetCore now exposes /engine/durable-executions/runtime, /engine/durable-executions/runtime/streams/{streamId}, /engine/durable-executions/runtime/behaviors/{behaviorId}, /engine/durable-executions/runtime/modules/{moduleId}, and /engine/durable-executions/runtime/transports/{transportId} as direct operator routes derived from the same shared runtime truth
• focused composition, hosting, package-surface, component-doc, roadmap, backlog, project-memory, and reference-doc coverage now lock the durable live-state contract plus the new public surface

ENG-113 Phase 12 durable execution timers and signals coordination baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-112, operators could see per-stream durable posture, but they still had no engine-owned answer for which streams were waiting on durable timers or external signals
• durable workflow authors still had to encode timer/signal waits indirectly even though the shared durable strategy already owned the truthful 200 / 202 / 204 execution posture
• ASP.NET Core hosts still had no direct /engine/* filters for pending durable timers or signals, which made it harder to find streams blocked on the same coordination trigger

Acceptance:

• Cephalon.Abstractions exposes host-agnostic pending timer/signal contracts for durable coordination
• DurableExecutionStepResult<TOutput> and DurableExecutionRuntimeState can surface pending timers/signals without inventing a second workflow registry beside the shared durable runtime
• /engine/snapshot and ASP.NET Core operator routes can filter active durable state by pending timer or pending signal
• docs, backlog, roadmap, project memory, reference docs, and focused composition/hosting/tooling coverage stay aligned with the shipped timer/signal scope while compensation helpers remain later work

Delivered:

• Cephalon.Abstractions now exposes DurableExecutionPendingTimer and DurableExecutionPendingSignal; DurableExecutionRuntimeState now carries pending timers, pending signals, derived coordination posture, and next-due timer data; and IDurableExecutionRuntimeStateCatalog now adds pending timer/signal filter methods
• Cephalon.Behaviors.Patterns now lets DurableExecutionStepResult<TOutput> declare pendingTimers plus pendingSignals, and DurableExecutionStrategy now emits a truthful waiting posture with 202 when no local output remains but durable timer/signal coordination is still pending
• Cephalon.Engine continues projecting the same snapshot.DurableExecutionStates surface, now with additive timer/signal coordination data instead of creating a second workflow snapshot
• Cephalon.AspNetCore now exposes /engine/durable-executions/runtime/timers, /engine/durable-executions/runtime/timers/{timerId}, /engine/durable-executions/runtime/signals, and /engine/durable-executions/runtime/signals/{signalId} as direct operator routes derived from the same shared runtime truth
• focused composition, hosting, package-surface, component-doc, roadmap, backlog, project-memory, and reference-doc coverage now lock the durable timer/signal coordination contract plus the new public surface

ENG-114 Phase 12 durable execution compensation helper baseline

Status: done Estimate: 5 Completed: April 19, 2026

Why:

• after ENG-113, operators could see pending durable timers/signals, but they still had no engine-owned answer for which streams exposed operator-facing compensation actions
• durable workflow authors still had no shared way to publish recovery guidance without inventing a second workflow engine or host-only workflow registry beside the shared replay/runtime-state truth
• ASP.NET Core hosts still had no direct /engine/* filters for streams exposing the same durable compensation action

Acceptance:

• Cephalon.Abstractions exposes host-agnostic durable compensation-helper contracts for operator-facing recovery guidance
• DurableExecutionStepResult<TOutput> and DurableExecutionRuntimeState can surface available compensation actions while preserving the shared IEventStore replay contract and runtime-state truth
• /engine/snapshot and ASP.NET Core operator routes can filter active durable state by available compensation action
• docs, backlog, roadmap, project memory, reference docs, and focused composition/hosting/tooling coverage stay aligned while compensation metadata remains additive instead of auto-executing it

Delivered:

• Cephalon.Abstractions now exposes DurableExecutionCompensationAction; DurableExecutionRuntimeState now carries compensation actions plus derived helper-availability posture; and IDurableExecutionRuntimeStateCatalog now adds compensation filter methods
• Cephalon.Behaviors.Patterns now lets DurableExecutionStepResult<TOutput> declare compensationActions, reports them through the shared durable runtime-state catalog, and keeps them additive over the same replay/state truth instead of treating them as pending coordination
• Cephalon.Engine continues projecting the same snapshot.DurableExecutionStates surface, now with additive compensation-helper metadata instead of creating a second durable workflow answer
• Cephalon.AspNetCore now exposes /engine/durable-executions/runtime/compensations and /engine/durable-executions/runtime/compensations/{compensationId} as direct operator routes derived from that same shared runtime truth
• focused composition, hosting, package-surface, component-doc, roadmap, backlog, project-memory, and reference-doc coverage now lock the durable compensation-helper contract plus the new public surface

ENG-115 Phase 12 saga choreography authoring helper baseline

Status: done Estimate: 3 Completed: April 19, 2026

Why:

• after ENG-108 and ENG-110, the choreography runtime path existed, but behavior authors still had to hand-shape SagaChoreographyStepResult and SagaChoreographyPublication details even for common event-reactor flows
• module authors still had no higher-level host-agnostic authoring path for choreography behaviors that preserved the shared ABT contract without inventing a second choreography registry
• the baseline still lacked a shared typed helper for JSON publications, which made it too easy for hosts or modules to drift on serializer defaults or reach for Cephalon.Eventing directly

Acceptance:

• Cephalon.Behaviors.Patterns exposes additive choreography authoring-helper contracts while staying host-agnostic
• choreography authors can create typed JSON publications through shared helpers without replacing the existing SagaChoreographyPublication contract or hard-depending on Cephalon.Eventing
• ChoreographySagaExecutionStrategy accepts the new helper result contracts while preserving the current 200 / 202 / 204 semantics and existing publisher handoff
• docs, backlog, roadmap, project memory, reference docs, and focused composition/tooling coverage stay aligned while the explicit eventing bridge remains optional and truthful

Delivered:

• Cephalon.Behaviors.Patterns now exposes ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, and SagaChoreographyStepResult<TOutput> so choreography authors can keep typed local output and publication intent on the same shared ABT contract
• SagaChoreographyPublication now exposes typed JSON helper factories for normal and compensation publications, preserving JsonSerializerDefaults.Web without moving publication ownership into Cephalon.Eventing
• ChoreographySagaExecutionStrategy now normalizes any ISagaChoreographyStepResult, keeping the runtime source of truth, publisher path, and existing HTTP posture unchanged
• focused composition and tooling coverage now lock the authoring-helper surface, source-generator compatibility, package-surface truth, and the shared choreography runtime contract without introducing a second choreography registry

ENG-116 Phase 12 saga choreography runtime catalog baseline

Status: done Estimate: 3 Completed: April 19, 2026

Why:

• after ENG-108, ENG-110, and ENG-115, choreography authoring and the explicit eventing bridge existed, but operators still had no host-agnostic catalog that answered which choreography behaviors were active, which modules owned them, which transports exposed them, and what result contract shape they used
• /engine/snapshot still stopped short of carrying a first-class choreography runtime answer even though durable execution already projected both static operator truth and live per-stream posture
• ASP.NET Core hosts still lacked direct /engine/* routes for choreography ownership and routing truth, which made choreography visibility depend on broader behavior catalogs or the optional eventing bridge surface instead of a dedicated choreography runtime contract

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic choreography runtime catalog and typed descriptor
• Cephalon.Behaviors.Patterns derives that runtime answer from shared behavior topology plus registered implementation types without inventing a second workflow registry
• Cephalon.Engine projects additive snapshot.SagaChoreographies through optional service resolution
• ASP.NET Core hosts expose /engine/saga-choreographies plus id/module/transport drill-down routes while keeping live publication-state tracking and eventing-bridge truth as separate later slices
• docs, backlog, roadmap, project memory, reference docs, and focused composition/hosting/tooling coverage stay aligned with the shipped choreography operator surface

Delivered:

• Cephalon.Abstractions now exposes SagaChoreographyRuntimeDescriptor plus ISagaChoreographyRuntimeCatalog as the host-agnostic read layer for active choreography behavior ownership, transports, feature gates, result-contract shape, and operator-facing metadata
• Cephalon.Behaviors.Patterns now derives that static choreography catalog from IBehaviorCatalog plus IBehaviorTypeRegistry, classifying authoring model and result shape from the shared choreography contracts instead of inventing a second choreography registry
• Cephalon.Engine now projects additive snapshot.SagaChoreographies through optional service resolution so the engine core stays host-agnostic while exposing the choreography runtime answer
• Cephalon.AspNetCore now exposes /engine/saga-choreographies, /engine/saga-choreographies/{behaviorId}, /engine/saga-choreographies/modules/{moduleId}, and /engine/saga-choreographies/transports/{transportId} as direct operator routes over the shared choreography catalog
• focused composition, hosting, and tooling coverage now lock the choreography runtime catalog, snapshot projection, ASP.NET Core operator routes, and public package surface without claiming live publication-state ownership or collapsing the explicit eventing bridge into the static choreography runtime answer

ENG-117 Phase 12 saga choreography live publication-state baseline

Status: done Estimate: 4 Completed: April 19, 2026

Why:

• after ENG-116, operators could query which choreography behaviors were active, but they still could not see whether the shared choreography execution path had recently accepted or failed one publication handoff, whether that publication was compensation work, or which channel, correlation, and transport context it belonged to
• /engine/snapshot still stopped short of carrying a first-class live choreography publication answer even though durable execution already exposed both static runtime topology and live runtime-state posture through one introspection payload
• the explicit Cephalon.Eventing.Behaviors bridge and downstream event-dispatch runtime already owned their own truth, so the missing slice was a choreography-owned publication-state surface that reported handoff observations without pretending to replace eventing-bridge ownership or downstream broker dispatch results

Acceptance:

• Cephalon.Abstractions exposes a host-agnostic choreography publication-state contract and runtime-state catalog
• Cephalon.Behaviors.Patterns reports accepted and failed publication handoff observations directly from ChoreographySagaExecutionStrategy without inventing a second choreography publisher registry
• Cephalon.Engine projects additive snapshot.SagaChoreographyPublicationStates through optional service resolution
• ASP.NET Core hosts expose /engine/saga-choreographies/runtime plus publication, behavior, module, transport, channel, correlation, compensation, and failure drill-down routes while preserving eventing-bridge and downstream dispatch truth as separate surfaces
• docs, backlog, roadmap, project memory, reference docs, and focused composition/hosting/tooling coverage stay aligned with the shipped live publication-state answer

Delivered:

• Cephalon.Abstractions now exposes SagaChoreographyPublicationRuntimeState plus ISagaChoreographyPublicationRuntimeStateCatalog as the host-agnostic read layer for the latest accepted-or-failed choreography publication handoff observations, including source module, transport ids, channel id, correlation, compensation posture, publisher type, counts, and operator-facing error metadata
• Cephalon.Behaviors.Patterns now reports live publication observations directly from ChoreographySagaExecutionStrategy, keeping the shared strategy as the source of choreography handoff truth while preserving explicit ISagaChoreographyPublisher replacements and the separate Cephalon.Eventing.Behaviors bridge/runtime story
• Cephalon.Engine now projects additive snapshot.SagaChoreographyPublicationStates through optional service resolution so the engine core stays host-agnostic while exposing the merged choreography publication-state answer
• Cephalon.AspNetCore now exposes /engine/saga-choreographies/runtime, /engine/saga-choreographies/runtime/publications/{publicationStateId}, /engine/saga-choreographies/runtime/behaviors/{behaviorId}, /engine/saga-choreographies/runtime/modules/{moduleId}, /engine/saga-choreographies/runtime/transports/{transportId}, /engine/saga-choreographies/runtime/channels/{channelId}, /engine/saga-choreographies/runtime/correlations/{correlationId}, /engine/saga-choreographies/runtime/compensations, and /engine/saga-choreographies/runtime/failures as direct operator routes over the shared choreography publication-state catalog
• focused composition, hosting, and tooling coverage now lock the choreography publication-state catalog, snapshot projection, ASP.NET Core operator routes, and public package surface without collapsing downstream event-dispatch ownership into the choreography runtime answer

ENG-118 Phase 12 saga choreography capability-publication follow-through

Status: done Estimate: 4 Completed: April 19, 2026

Why:

• after ENG-117, operators could query the choreography runtime and publication-state surfaces directly, but /engine/capabilities still exposed only the coarse behaviors.saga-choreography baseline instead of telling them whether the static runtime catalog and live publication-state services were actually active
• choreography capability truth needed to stay module-backed and activation-driven; inventing a synthetic engine-owned runtime capability would blur provenance, especially because the explicit Cephalon.Eventing.Behaviors bridge already owns a separate durable handoff capability answer
• hosts and low-ceremony consumers needed deterministic manifest metadata that reflected whether AddBehaviorPatterns() had actually registered ISagaChoreographyRuntimeCatalog and ISagaChoreographyPublicationRuntimeStateCatalog

Acceptance:

• Cephalon.Behaviors publishes behaviors.saga-choreography.runtime-catalog only when AddBehaviorPatterns() activates ISagaChoreographyRuntimeCatalog
• Cephalon.Behaviors publishes behaviors.saga-choreography.publication-state only when AddBehaviorPatterns() activates ISagaChoreographyPublicationRuntimeStateCatalog
• capability metadata explains pack, pattern, surface, activation, service contract, snapshot field, ASP.NET Core route, and publication-state ownership truth without collapsing eventing-bridge ownership into the choreography runtime answer
• focused composition and hosting coverage lock the conditional capability-publication behavior through both the runtime manifest and /engine/capabilities
• docs, backlog, roadmap, project memory, and GitHub tracking stay aligned with the shipped module-backed capability-publication follow-through

Delivered:

• Cephalon.Behaviors now inspects whether AddBehaviorPatterns() actually registered ISagaChoreographyRuntimeCatalog and ISagaChoreographyPublicationRuntimeStateCatalog before it publishes the additive behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state capabilities
• both new capability entries stay sourced from the behaviors module and now publish stable metadata for the owning pattern pack, service contract, snapshot field, activation path, and ASP.NET Core route so /engine/capabilities explains which choreography operator surfaces are active without inventing a synthetic engine runtime owner
• the publication-state capability metadata now also records its choreography-strategy ownership, accepted-versus-failed outcome scope, and explicit separation from the additive eventing.behaviors.saga-choreography bridge capability
• focused composition and hosting coverage now prove the positive and negative activation paths through the runtime manifest and /engine/capabilities so the module-backed capability answer stays truthful when pattern services are absent

ENG-069 Event-dispatch runtime operator-surface baseline

Status: done Estimate: 5

Why:

• the current eventing baseline could report live dispatch state, but its descriptor and state read contracts still lived in Cephalon.Eventing instead of the host-agnostic abstraction layer that other runtime catalogs use
• /engine/snapshot still stopped short of exposing a first-class event-dispatch runtime answer even though operators already needed to understand both configured dispatch ownership and the latest reported state
• ASP.NET Core hosts still lacked direct /engine/* operator routes for event-dispatch runtimes and live dispatch state, which forced tooling to reconstruct answers indirectly from broader technology surfaces
• the showcase sample had the pieces for outbox-backed publication, but it did not yet prove the optional Wolverine-managed dispatch path and the new operator routes end to end

Acceptance:

• host-agnostic read contracts for configured event-dispatch runtimes and live event-dispatch state live in Cephalon.Abstractions
• /engine/snapshot carries additive EventDispatchRuntimes and EventDispatchStates answers when the corresponding catalogs are active
• ASP.NET Core hosts expose /engine/event-dispatch-runtimes, /engine/event-dispatch-runtimes/{dispatchRuntimeId}, /engine/event-dispatches, and /engine/event-dispatches/{outboxId}
• Cephalon.Eventing.Wolverine projects its managed loop through the new operator surfaces without leaking Wolverine APIs into the abstraction layer
• the showcase sample wires one optional Wolverine path so hosting tests can prove the new routes and runtime snapshot truthfully without turning Wolverine into an engine requirement

Delivered:

• Cephalon.Abstractions now ships EventDispatchRuntimeDescriptor, EventDispatchRuntimeState, IEventDispatchRuntimeCatalog, and IEventDispatchRuntimeDescriptorCatalog as the host-agnostic read layer for configured dispatch ownership and latest reported dispatch state
• Cephalon.Eventing now keeps registration, reporting, and catalog implementation in the companion pack while consuming the abstraction-layer contracts for public reads, including a dedicated EventDispatchRuntimeDescriptorCatalog
• Cephalon.Engine now projects additive EventDispatchRuntimes and EventDispatchStates into RuntimeIntrospectionSnapshot through optional service resolution so the engine core stays additive and host-agnostic
• Cephalon.AspNetCore now exposes /engine/event-dispatch-runtimes, /engine/event-dispatch-runtimes/{dispatchRuntimeId}, /engine/event-dispatches, and /engine/event-dispatches/{outboxId} as direct operator routes
• Cephalon.Eventing.Wolverine now reports its managed dispatch loop through the new runtime-descriptor/state surfaces without holding scoped dependencies incorrectly in singleton services, and the showcase sample now wires the optional Wolverine pack so those routes stay truthful end to end
• hosting, composition, tooling, reference-doc, and showcase coverage now lock the new operator contract plus the moved public surface

Sprint history and next 4 sprints

Historical sprint buckets below are retrospective planning groups used to backfill iteration and estimate metadata for delivered work.

Upcoming sequence from the April 2026 maturity reset:

Sprint 42

• ENG-230 Engine surface maturity model and audit baseline

Sprint 43

• ENG-231 Truthful managed event-subscription execution baseline

Sprint 44

• ENG-232 Agentics tool execution and run-state baseline

Sprint 45

• ENG-233 Retrieval indexing, query execution, and freshness baseline (shipped)

Sprint 46

• ENG-234 Multi-tenancy governance, membership, and domain workflow companion split (shipped)

Sprint 47

• ENG-235 Multi-tenancy governance membership evaluation baseline (shipped)

Sprint 48

• ENG-236 Multi-tenancy governance invitation validation baseline (shipped)

Sprint 49

• ENG-237 Multi-tenancy governance domain ownership validation baseline (shipped)

Sprint 50

• ENG-238 Multi-tenancy governance action decision baseline (shipped)

Sprint 51

• ENG-239 Multi-tenancy governance action workflow execution baseline (shipped)

Sprint 52

• ENG-240 Multi-tenancy governance durable action store baseline (shipped)

Sprint 53

• ENG-241 Multi-tenancy governance durable membership store baseline (shipped)

Sprint 54

• ENG-242 Multi-tenancy governance durable invitation store baseline (shipped)

Sprint 55

• ENG-243 Multi-tenancy governance durable domain ownership store baseline (shipped)

Sprint 56

• ENG-244 Multi-tenancy governance domain ownership verification workflow baseline (shipped)

Sprint 57

• ENG-245 Multi-tenancy governance domain ownership proof evaluation baseline (shipped)

Sprint 58

• ENG-246 Multi-tenancy governance domain ownership proof challenge issuance baseline (shipped)

Sprint 59

• ENG-247 Multi-tenancy governance domain ownership proof publication planning baseline (shipped)

Sprint 60

• ENG-248 Multi-tenancy governance domain ownership HTTP proof collection baseline (shipped)

Sprint 61

• ENG-249 Multi-tenancy governance domain ownership proof verification runner baseline (shipped)

Sprint 62

• ENG-250 Multi-tenancy governance domain ownership DNS TXT proof collection baseline (shipped)

Sprint 63

• ENG-251 Multi-tenancy governance domain ownership proof polling runner baseline (shipped)

Sprint 64

• ENG-252 Multi-tenancy governance automatic background proof polling baseline (shipped)

Sprint 65

• ENG-253 Multi-tenancy governance HTTP proof publication baseline (shipped)

Sprint 66

• ENG-254 Multi-tenancy governance tenant administration workflow baseline (shipped)

Sprint 67

• ENG-255 Multi-tenancy governance ASP.NET Core tenant administration endpoint baseline (shipped)

Sprint 68

• ENG-256 Multi-tenancy governance invitation delivery dispatch baseline (shipped)

Sprint 69

• ENG-257 Multi-tenancy governance HTTP invitation delivery sender baseline (shipped)

Sprint 70

• ENG-258 Multi-tenancy governance HTTP invitation delivery webhook signing baseline (shipped)

Sprint 71

• ENG-259 Multi-tenancy governance HTTP invitation delivery retry baseline (shipped)

Sprint 72

• ENG-260 Multi-tenancy governance HTTP invitation delivery idempotency baseline (shipped)

Sprint 73

• ENG-261 Multi-tenancy governance invitation delivery status reconciliation baseline (shipped)

Sprint 74

• ENG-262 Behavior REST profile runtime ownership metadata baseline (shipped)

Sprint 75

• ENG-263 Eventing subscription execution binding catalog baseline (shipped)

Sprint 76

• ENG-264 Eventing subscription execution readiness catalog baseline (shipped)

Sprint 77

• ENG-265 Eventing subscription readiness operator-surface baseline (shipped)

Sprint 78

• ENG-266 Agentics tool-run operator-surface baseline (shipped, issue #775)

Sprint 79

• ENG-267 Retrieval knowledge-index operator-surface baseline (shipped, issue #776)

Sprint 80

• ENG-268 Retrieval reindex operator-action baseline (shipped, issue #777)

Sprint 81

• ENG-269 Agentics tool execution operator-action baseline (shipped, issue #778)

Sprint 82

• ENG-270 Retrieval background reindex scheduler baseline (shipped, issue #779)

Sprint 83

• ENG-271 Eventing in-process subscription execution baseline (shipped, issue #780)

Sprint 84

• ENG-272 Eventing publication operator action baseline (shipped, issue #781)

Sprint 85

• ENG-273 Eventing in-process subscription retry baseline (shipped, issue #782)

Sprint 86

• ENG-274 Eventing in-process subscription idempotency baseline (shipped, issue #783)

Sprint 87

• ENG-275 Eventing publication runtime operator-state baseline (shipped, issue #784)

Sprint 88

• ENG-276 Wolverine bounded subscription retry terminal failure (shipped, issue #785)

Sprint 89

• ENG-277 Wolverine dispatch terminal retry failure (shipped, issue #786)

Sprint 90

• ENG-278 Wolverine dispatch publish-exception terminal proof (shipped, issue #787)

Sprint 91

• ENG-279 First-class event-dispatch terminal-failure runtime posture (shipped, issue #788)

Sprint 92

• ENG-280 Agentics bounded in-process retry posture (shipped, issue #789)

Sprint 93

• ENG-281 Agentics process-local duplicate-run idempotency posture (shipped, issue #790)

Sprint 94

• ENG-282 Agentics approval-required and terminal-failure operator posture (shipped, issue #791)

Sprint 95

• ENG-283 Retrieval query operator action seam (shipped, issue #792)
• ENG-284 Multi-tenancy invitation delivery status callback endpoint baseline (shipped, issue #793)
• ENG-285 Multi-tenancy invitation delivery status callback signature verification baseline (shipped, issue #800)
• ENG-286 Multi-tenancy invitation delivery status callback replay protection baseline (shipped, issue #801)
• ENG-287 Multi-tenancy invitation delivery status observation store baseline (shipped, issue #802)
• ENG-288 Multi-tenancy invitation delivery status observation endpoint baseline (shipped, issue #803)
• ENG-289 Multi-tenancy invitation delivery dispatch endpoint baseline (shipped, issue #804)
• ENG-290 Multi-tenancy invitation delivery durable retry queue baseline (shipped, issue #805)

Sprint 96

• ENG-291 Multi-tenancy invitation delivery background retry scheduling baseline (shipped, issue #806)

Sprint 97

• ENG-292 Multi-tenancy invitation delivery retry execution coordination baseline (shipped, issue #807)

Sprint 98

• ENG-293 Multi-tenancy invitation delivery SMTP sender baseline (shipped, issue #808)

Sprint 99

• ENG-294 Multi-tenancy invitation delivery SendGrid sender baseline (shipped, issue #809)

Sprint 100

• ENG-295 Multi-tenancy invitation delivery SendGrid Event Webhook callback translation baseline (shipped, issue #810)

Sprint 101

• ENG-296 Multi-tenancy invitation delivery SendGrid signed Event Webhook verification (shipped, issue #811)

Sprint 102

• ENG-297 Multi-tenancy invitation delivery SendGrid signed Event Webhook replay protection baseline (shipped, issue #812)

Sprint 103

• ENG-298 Multi-tenancy invitation delivery SendGrid event-id idempotency baseline (shipped, issue #813)

Sprint 104

• ENG-299 Multi-tenancy invitation delivery Mailgun sender baseline (shipped, issue #814)

Sprint 105

• ENG-300 Multi-tenancy invitation delivery Mailgun webhook callback translation baseline (shipped, issue #815)

Sprint 106

• ENG-301 Multi-tenancy invitation delivery Mailgun signed webhook verification baseline (shipped, issue #816)

Sprint 107

• ENG-302 Multi-tenancy invitation delivery Mailgun signed webhook replay protection baseline (shipped, issue #817)

Sprint 108

• ENG-303 Multi-tenancy invitation delivery Mailgun event-id idempotency baseline (shipped, issue #818)

Sprint 109

• ENG-304 Multi-tenancy invitation delivery Microsoft Graph sender baseline (shipped, issue #819)

Sprint 110

• ENG-305 Multi-tenancy invitation delivery Microsoft Graph Azure Identity token provider baseline (shipped, issue #820)

Sprint 111

• ENG-306 Multi-tenancy invitation delivery Amazon SES sender baseline (shipped, issue #821)

Sprint 112

• ENG-307 Multi-tenancy invitation delivery Amazon SES SNS callback translation baseline (shipped, issue #822)

Sprint 113

• ENG-308 Multi-tenancy invitation delivery Amazon SES SNS signature verification baseline (shipped, issue #823)

Sprint 114

• ENG-309 Multi-tenancy invitation delivery Amazon SES SNS replay protection baseline (shipped, issue #824)

Later / not scheduled yet

• actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond status transitions, distributed or provider-backed membership/invitation/domain/action-store backends, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, distributed retry queues, provider-specific or distributed callback inboxes, cross-node callback replay protection, distributed event-id ledgers, provider-specific callback translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, identity-provider synchronization, public onboarding, and tenant-admin UI/backoffice flows when Cephalon.MultiTenancy.Governance or provider packs truly own those paths

Foundation Sprint 1

• ENG-000 App model and blueprint contract
• ENG-001 Module discovery from assemblies
• ENG-002 Lifecycle hooks baseline
• ENG-003 Engine options and policy baseline
• ENG-004 Manifest v2

Foundation Sprint 2

• ENG-006 Worker adapter baseline
• ENG-007 ASP.NET Core contribution model baseline
• ENG-008 Observability baseline
• ENG-009 Blueprint-aware scaffolding and CLI baseline

Foundation Sprint 3

• ENG-014 Protocol adapter packages baseline
• ENG-015 Benchmark suite baseline
• ENG-025 Technology companion packages baseline

Adoption Sprint 0

• ENG-016 Blueprint sample suite
• ENG-017 dotnet new / template-pack support
• ENG-018 Module SDK and authoring path

Operational Sprint 0

• ENG-019 Runtime failure and restart policy
• ENG-020 Operational health and telemetry exports
• ENG-021 Benchmark guardrails in validation flow
• ENG-024 Explicit package assembly loading baseline
• ENG-023 GitHub Actions release-validation baseline

Platform Sprint 0

• ENG-012 Capability permissions and trust policy

Sprint 1

• ENG-005 Engine API and package surface hardening
• ENG-026 GraphQL transport adapter
• ENG-027 DocFX XML-comment readiness beyond shipped packages
• ENG-029 Huawei Cloud observability exporter wiring and hosted Huawei Cloud defaults on top of the OTLP baseline
• ENG-029 Alibaba Cloud observability exporter wiring and hosted Alibaba Cloud defaults on top of the OTLP baseline
• ENG-029 Red Hat OpenShift collector wiring and hosted OpenShift defaults on top of the OTLP baseline
• ENG-029 DigitalOcean collector wiring and hosted DigitalOcean defaults on top of the OTLP baseline
• ENG-029 VMware Tanzu proxy handoff and hosted Tanzu defaults on top of the OTLP baseline
• ENG-029 Kubernetes collector wiring and hosted Kubernetes defaults on top of the OTLP baseline

Sprint 2

• operational hardening follow-through after the shipped health, telemetry, and CI baselines
• shipped OpenTelemetry companion packaging plus Cassandra contact-point health plus ClickHouse analytics health plus Consul control-plane health plus Elasticsearch cluster health plus HTTP external API, Kafka broker metadata, Memcached cache, MongoDB document database, MQTT broker, MySQL database, NATS broker, Neo4j graph database, OpenSearch cluster health, Oracle database, Postgres database, RabbitMQ broker, Redis/cache, and SQL Server dependency-health companions, together with the shared diagnostics/event-id catalog for active packages, opt-in ASP.NET Core request/response logging with trace correlation, and explicit release-validation guidance for health/export conventions

Sprint 3

• shipped first execution-graph contract baseline plus hosted-execution follow-through under ENG-013
• shipped package distribution and provenance follow-through beyond the original package-loading baseline
• shipped repo-wide XML-comment hygiene for test harnesses through explicit xUnit visibility rules plus tooling-backed guards under ENG-028
• ENG-029 self-hosted OTLP collector/runtime-default follow-through plus the shipped Azure Monitor, AWS, GCP, Huawei Cloud, Alibaba Cloud, Red Hat OpenShift, DigitalOcean, VMware Tanzu, Kubernetes, Cloudflare/downstream provider authoring guidance, Grafana Cloud, and New Relic slices

Sprint 4

• ENG-033 cross-platform validation and shell parity baseline
• ENG-034 first-run adoption and environment doctor path

Sprint 5

• ENG-035 external module package lifecycle prove-out

Sprint 6

• ENG-036 containerized local runtime and operations baseline

Sprint 7

• ENG-037 generated app local package-feed bootstrap baseline

Sprint 8

• ENG-038 generated app published-output and deployment baseline

Sprint 9

• ENG-039 generated app Linux systemd deployment baseline

Sprint 10

• ENG-040 generated app Windows Service deployment baseline

Sprint 11

• ENG-041 generated app IIS deployment baseline

Sprint 12

• ENG-042 generated app Azure App Service deployment baseline

Sprint 13

• ENG-043 generated app Azure Container Apps deployment baseline

Sprint 14

• ENG-044 generated app Kubernetes deployment baseline

Sprint 15

• ENG-045 generated app container-image publishing baseline

Sprint 16

• ENG-046 app-model taxonomy and catalog expansion baseline
• ENG-047 structured engine configuration and runtime surface baseline for data, identity, tenancy, audit, and messaging
• ENG-048 host-agnostic data, authorization, tenancy, audit, and id contract baseline

Sprint 17

• ENG-049 relational Entity Framework CQRS, projections, outbox, and Sfid companion baseline
• ENG-050 eventing runtime uplift and Wolverine companion baseline

Sprint 18

• ENG-051 identity and authorization companion baseline
• ENG-052 multi-tenancy and audit companion baseline
• ENG-053 CLI, scaffolding, template-pack, and sample alignment for phase 8

Sprint 19

• ENG-055 phase 8 validation, benchmark, and runtime-truth matrix
• ENG-056 phase 8 docs, XML comments, component-guide, and reference-doc alignment

Sprint 20

• ENG-058 M1 ABT foundation: IAppBehavior, IBehaviorContext, BehaviorDispatcher, BehaviorExecutionSlot, CompatibilityMatrix, hosting — Shipped commit 9d657da · 499/499 tests

Sprint 21

• ENG-058 M2 HTTP Transport Pack: 7 HTTP bindings (rest, jsonrpc, graphql, graphql-sse, graphql-ws, sse, ws), LazyTransportBinding — Shipped commit c957966 · 516/516 tests

Sprint 22

• ENG-058 M3 Messaging Transport Pack: InMemory, RabbitMQ, Kafka bindings; M2 CTS leak fix — Shipped commit 9183407 · 527/527 tests

Sprint 23

• ENG-058 M4 Pattern Execution Strategies: IBehaviorExecutionStrategy, 5 strategies (cqrs, event-driven, saga-step, process-manager, direct), ISagaStateStore, IProcessCheckpointStore, FrozenDictionary registry; IBehaviorContext.CorrelationId; IProcessCompletion — Shipped commit cc2ab0a · 575/575 tests

Sprint 24

• ENG-058 M5 Source Generator: Roslyn IIncrementalGenerator + DiagnosticAnalyzer (Cephalon.Behaviors.SourceGen); ABT0010–ABT0013 diagnostics; ForAttributeWithMetadataName; emits BehaviorRegistrationHints.g.cs — Shipped commit 8455b9a · 584/584 tests
• ENG-058 M6 Runtime Integration: BehaviorRuntimeContributor (ITechnologyRuntimeContributor), IBehaviorAdvisory system (contributor/catalog/severity), IBehaviorContext.EventStore (IEventStore? wiring), BehaviorDiagnostics EventId 5100-5109 — Shipped commit 62d386c · 592/592 tests

Sprint 25

• ENG-054 Phase 10 non-relational provider baseline: Cephalon.Data.MongoDB (IOutbox + IInbox backed by MongoDB collections, idempotent staging via unique index, outbox/inbox runtime surface contribution, data.mongodb / data.document-store capabilities), Cephalon.EventSourcing.MongoDB (IEventStore with optimistic concurrency via compound unique index on StreamId+StreamVersion, System.Text.Json serialization, IAsyncEnumerable stream replay), MongoDB.Driver 3.4.0 in CPM, 12 integration tests via EphemeralMongo, full component docs — Shipped commit f94dc28 · 599/599 tests

Sprint 26

• ENG-054 Redis non-relational provider: Cephalon.Data.Redis (IOutbox backed by Redis Hash + Sorted Set with idempotent KeyNotExists transaction condition, IInbox backed by Redis Set with naturally idempotent SADD, outbox/inbox runtime surface contribution, data.redis / data.key-value-store capabilities), Cephalon.EventSourcing.Redis (IEventStore via Redis Streams with XADD/XRANGE, optimistic pre-insert version check, System.Text.Json serialization, IAsyncEnumerable stream replay), StackExchange.Redis 2.8.16 in CPM, 8 composition tests (abortConnect=false, no live Redis required), full component docs — Shipped · 607/607 tests

Sprint 27

• ENG-054 Neo4j graph-store non-relational provider: Cephalon.Data.Neo4j (IOutbox + IInbox backed by Neo4j graph nodes, idempotent staging via Cypher MERGE on messageId, data.neo4j / data.graph-store capabilities), Cephalon.EventSourcing.Neo4j (IEventStore with optimistic concurrency via IS NODE KEY constraint on streamId+streamVersion, System.Text.Json serialization, IAsyncEnumerable stream replay), Neo4j.Driver 6.0.0 already in CPM, 8 composition tests (no live Neo4j required — driver connects lazily), full component docs — Shipped · 615/615 tests

Sprint 28

• ENG-054 Cassandra wide-column non-relational provider: Cephalon.Data.Cassandra (IOutbox + IInbox backed by Cassandra tables, idempotent staging via LWT INSERT IF NOT EXISTS, data.cassandra / data.wide-column-store capabilities), Cephalon.EventSourcing.Cassandra (IEventStore with composite PK on stream_id+stream_version, LWT concurrency detection, System.Text.Json serialization, IAsyncEnumerable stream replay), CassandraCSharpDriver 3.22.0 already in CPM, 8 composition tests (no live Cassandra required — driver connects lazily), full component docs — Shipped · 624/624 tests

Sprint 29

• ENG-054 ClickHouse analytics non-relational provider: Cephalon.Data.ClickHouse (IOutbox + IInbox backed by ClickHouse ReplacingMergeTree tables, eventual idempotency via ORDER BY deduplication + FINAL reads, data.clickhouse / data.analytics-store capabilities), Cephalon.EventSourcing.ClickHouse (IEventStore with MergeTree ORDER BY (stream_id, stream_version), application-layer optimistic concurrency, System.Text.Json serialization, IAsyncEnumerable stream replay), ClickHouse.Driver 1.0.2 already in CPM, 8 composition tests (no live ClickHouse required — connection created per-operation), full component docs — Shipped · 632/632 tests

Infrastructure — Phase 1 Developer Experience

• Solution filter files: core.slnf, data.slnf, observability.slnf, aspnetcore.slnf added to repo root for IDE-level project filtering
• Scaffolding scripts: scripts/New-ProviderPack.ps1 and scripts/New-ObservabilityPack.ps1 automate the artifact creation steps when adding new provider companion packs

Sprint 30

• ENG-054 Elasticsearch + OpenSearch search-store non-relational provider: Cephalon.Data.Elasticsearch (IOutbox + IInbox backed by Elasticsearch indices, idempotent staging via op_type=create (409 swallow), data.elasticsearch / data.search-store capabilities), Cephalon.EventSourcing.Elasticsearch (IEventStore with compound document id {streamId}#{streamVersion} for uniqueness, application-layer optimistic concurrency, System.Text.Json serialization, IAsyncEnumerable stream replay), Cephalon.Data.OpenSearch (OpenSearch.Client mirror of Elasticsearch data pack, data.opensearch / data.search-store capabilities), Cephalon.EventSourcing.OpenSearch (OpenSearch mirror of Elasticsearch event store), Elastic.Clients.Elasticsearch 8.17.0 + OpenSearch.Client 1.8.0 in CPM, 8 composition tests (no live server required — client connects lazily), full component docs — Shipped · 640/640 tests

Sprint 31

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

Infrastructure — Phase 2 Developer Experience

• Test assembly split: Cephalon.Tests monolith (648 tests) split into Cephalon.Tests.Support (shared lib), Cephalon.Tests.Composition (327 tests — Composition + Behaviors + EventSourcing + Benchmarks), Cephalon.Tests.Hosting (200 tests — Hosting/Observability), Cephalon.Tests.Tooling (121 tests — Tooling + Scaffolding) — enables parallel test execution per assembly, faster incremental builds, and cleaner dependency boundaries — Shipped · 648/648 tests

Sprint 32

• backlog and roadmap alignment: ENG-054 status updated to done (all 9 non-relational provider families shipped), ENG-056 status updated to done (phase-8 docs and reference-doc alignment complete), ENG-057 status updated to done (event-sourcing follow-through baseline delivered through core contracts plus 10 provider implementations), roadmap sprint alignment extended through Sprint 31, Phase 10 planning notes updated to reflect completion

Sprint 33

• ENG-049 EF projection contributor: Cephalon.Data.EntityFramework now implements IProjectionContributor and registers EF-backed projection descriptors with data.projections.entity-framework capability plus projections runtime surface under data-management — closes projection persistence/runtime gap
• ENG-050 Wolverine dispatch observability: Cephalon.Eventing.Wolverine dispatch loop now instrumented with System.Diagnostics.ActivitySource (Producer spans per dispatch item) and System.Diagnostics.Metrics.Meter (attempts, successes, failures, retries counters + duration histogram), diagnostics convention extended from 4300-4303 to 4300-4305 — enables OpenTelemetry trace/metric capture
• ENG-051 status updated to done (all acceptance criteria met)
• ENG-055 validation script fix: scripts/validate-phase8-conventions.ps1 updated to use new test assembly paths (Cephalon.Tests.Composition, Cephalon.Tests.Hosting, Cephalon.Tests.Tooling) after Infrastructure Phase 2 test split — Shipped · 648/648 tests

Sprint 34

• comprehensive engine audit: WebSocket binding empty catch blocks replaced with high-performance [LoggerMessage] source-generated logging delegates (CA1848/CA1873 compliant), flaky test fix for MapCephalonExposesCapturedStartupFailuresWhenPolicyDoesNotFailFast using TryGetProperty pattern, architecture inventory and recommendations docs
• backlog alignment: ENG-049, ENG-050, ENG-052, ENG-053, ENG-055 status updated to done (all baseline acceptance criteria met, remaining work moved to follow-up sections), ENG-059 created for runtime hot-path benchmark expansion
• docs: docs/architecture-inventory.md (comprehensive engine component inventory), docs/architecture-recommendations.md (future pattern recommendations, deferred), docs/architecture.md cross-references, docs/engine-roadmap.md Sprint 33 entry and Phase 11/12/13 planning — Shipped · 648/648 tests

Sprint 35

• ENG-059 runtime hot-path benchmark expansion: 6 new benchmark classes covering data layer dispatch (query/command/result-command), behavior dispatch (frozen-dictionary + compiled delegate), authorization evaluation (RBAC allow/deny paths), tenant resolution (by-id/hostname/default-fallback), event sourcing (append/read/version), outbox staging — 13 new benchmarks
• benchmark support: BenchmarkHotPathTypes.cs with data stubs, behavior stubs, authorization policy module, InMemoryBenchmarkEventStore, InMemoryBenchmarkOutbox, BenchmarkDomainEvent
• guardrail catalog expanded from 10 to 23 entries, GuardrailValidatorTests updated
• benchmark project now references Cephalon.Behaviors for behavior dispatch measurement — Shipped · 648/648 tests

Sprint 36

• ENG-076 resilience contract and taxonomy baseline: Cephalon.Abstractions now exports ResilienceSelection, RetrySelection, TimeoutSelection, CircuitBreakerSelection, BulkheadSelection, and RateLimitingSelection; Cephalon.Engine now binds Engine:Resilience through matching settings types, projects the requested contract into AppProfile.Resilience, validates baseline numeric and algorithm values, and completes the built-in pattern taxonomy with onion-architecture plus anti-corruption-layer; Cephalon.AspNetCore now exposes /engine/resilience; the showcase sample now demonstrates the config contract; runtime enforcement through behavior/transport pipelines remains a later follow-through — Shipped · targeted composition tests 6/6 + hosting tests 1/1 + package-surface tests 52/52
• ENG-077 ASP.NET Core rate-limiting runtime baseline: Cephalon.Abstractions now exports IRateLimitingRuntimeCatalog plus RateLimitingRuntimeDescriptor; Cephalon.AspNetCore now enforces Engine:Resilience:RateLimiting for public HTTP endpoints through Microsoft.AspNetCore.RateLimiting, publishes /engine/rate-limiting plus /engine/rate-limiting/{policyId}, excludes operator/docs routes such as /engine, /health, /openapi, Scalar, /favicon.ico, and hosted reference docs, and keeps behavior-owned REST OpenAPI docs truthful by auto-publishing 429 when the limiter is active; /engine/snapshot now carries RateLimitingPolicies, and the showcase sample demonstrates the effective runtime surface end to end — Shipped · targeted hosting tests 7/7 + package-surface tests 52/52
• ENG-078 ASP.NET Core endpoint-scoped rate-limiting overrides: Cephalon.Abstractions now exports RateLimitingOverrideSelection, Cephalon.Engine now binds Engine:Resilience:RateLimiting:Overrides into AppProfile.Resilience, validates behavior/transport-scoped override intent, and Cephalon.AspNetCore now resolves named endpoint policies with behavior-aware precedence across module-owned REST routes plus generic behavior HTTP bindings while keeping /engine/rate-limiting, /engine/snapshot, and behavior-owned REST OpenAPI 429 answers truthful per endpoint; the showcase sample now demonstrates a behavior+transport override end to end — Shipped · targeted hosting tests 10/10 + package-surface tests 52/52
• ENG-079 behavior-execution resilience runtime baseline: Cephalon.Abstractions now exports BehaviorExecutionResilienceSelection, BehaviorResilienceRuntimeDescriptor, and IBehaviorResilienceRuntimeCatalog; Cephalon.Behaviors now inserts a shared execution middleware seam into BehaviorDispatcher, enforces the first shared timeout-plus-bulkhead baseline through Microsoft.Extensions.Resilience across behavior dispatch, normalizes effective timeout truth to the currently enforced single execution budget, suppresses disabled-only policy declarations, and publishes /engine/behavior-resilience plus snapshot.BehaviorResiliencePolicies; Cephalon.Behaviors.Http now also translates timeout and bulkhead rejections into truthful REST 503 / 429 responses while keeping behavior-owned REST OpenAPI status metadata aligned per route; retry and circuit breaker remain contract-only at this layer for now — Shipped · targeted composition tests 4/4 + hosting tests 3/3 + package-surface tests 52/52
• ENG-080 behavior-execution resilience overrides baseline: Cephalon.Abstractions now exports BehaviorExecutionResilienceOverrideSelection, extends BehaviorResilienceRuntimeDescriptor with targeted behavior/transport ids, and extends IBehaviorResilienceRuntimeCatalog with effective Resolve(behaviorId, transportId) lookup; Cephalon.Engine now binds additive Engine:Resilience:BehaviorExecution:Overrides into AppProfile.Resilience and validates scoped override intent; Cephalon.Behaviors now resolves default plus named override policies with behavior+transport > behavior > transport > default precedence, keeps explicit disable overrides visible in /engine/behavior-resilience plus snapshot.BehaviorResiliencePolicies, stamps active transport ids into dispatch metadata, and lets REST/OpenAPI 429 / 503 answers reflect the effective per-route behavior-execution policy instead of the shared default alone; the showcase sample now demonstrates a behavior+transport override end to end — Shipped · targeted composition tests 8/8 + hosting tests 4/4 + package-surface tests 52/52
• ENG-081 behavior-execution circuit-breaker runtime baseline: Cephalon.Abstractions now exports BehaviorResilienceExceptionContext, BehaviorResilienceExceptionHandling, and IBehaviorResilienceExceptionClassifier; Cephalon.Behaviors now enforces shared circuit-breaker policy through the existing behavior-execution middleware seam, classifies failures conservatively, keeps per-policy breaker state visible through /engine/behavior-resilience plus snapshot.BehaviorResiliencePolicies, and applies the same behavior/transport override resolution to timeout, circuit-breaker, and bulkhead answers; Cephalon.Behaviors.Http now also translates open-circuit rejections into truthful REST 503 responses with retry-after details while documenting 503 for routes whose effective circuit breaker can reject requests even when timeout is disabled — Shipped · targeted composition tests 8/8 + hosting tests 6/6 + package-surface tests 52/52
• ENG-082 behavior-execution retry eligibility baseline: Cephalon.Abstractions now exports BehaviorIdempotencyAttribute plus BehaviorIdempotencyMode, BehaviorResilienceExceptionContext now carries declared behavior idempotency, and Cephalon.Behaviors now resolves that contract during dispatch so the default resilience classifier can mark retry-eligible transient failures only for explicitly idempotent behaviors while /engine/behavior-resilience plus snapshot.BehaviorResiliencePolicies keep policy-level retryEligibilityMode = behavior-dependent truth and IBehaviorResilienceRuntimeCatalog.Resolve(behaviorId, transportId) can now answer per-behavior behaviorIdempotency plus retry eligibility as eligible, ineligible, or unknown; automatic retry execution itself remains a later follow-through — Shipped · targeted composition tests 10/10 + hosting tests 1/1 + package-surface tests 52/52
• ENG-083 behavior-execution retry runtime baseline: Cephalon.Behaviors now enforces shared retry policy in the existing behavior-execution middleware seam, keeps retry gated by explicit BehaviorIdempotencyAttribute plus classifier decisions for transient failures, composes retry with total timeout, per-attempt timeout, circuit breaker, and bulkhead in the shared dispatch pipeline, and publishes truthful retry attempts/backoff/delay/jitter metadata through /engine/behavior-resilience, IBehaviorResilienceRuntimeCatalog.Resolve(behaviorId, transportId), and snapshot.BehaviorResiliencePolicies; behavior- or transport-scoped overrides can now disable inherited retry for narrower surfaces without custom dispatch glue — Shipped · targeted composition tests 14/14 + hosting tests 1/1 + package-surface tests 52/52
• ENG-084 built-in GraphQL protocol split plus long-lived transport rate-limiting truth: Cephalon.AspNetCore.GraphQL now maps separate built-in GraphQL HTTP, schema, SSE, and WebSocket surfaces under the shared ApiRoutes:Prefixes contract (/graphql, /graphql/schema, /graphql-sse, and /graphql-ws by default), Cephalon.AspNetCore now canonicalizes built-in GraphQL transport ids as graphql, graphql-sse, and graphql-ws, and /engine/rate-limiting plus snapshot.RateLimitingPolicies now publish truthful long-lived metadata such as transportKind, transportSemantics, enforcementMoment, and longLivedTransportIds so stream/connection policies stop collapsing into generic endpoint labels — Shipped · GraphQL transport hosting tests 2/2 + targeted hosting regression 6/6
• ENG-085 GraphQL authoring helpers plus protocol-level route prove-out: Cephalon.AspNetCore.GraphQL now exposes shared ConfigureGraphQLMutation(...) and ConfigureGraphQLSubscription(...) helpers alongside query registration, IGraphQLModule now documents the shared authoring path plus the need for a concrete Hot Chocolate subscription provider when modules expose subscription fields, and the hosting coverage now proves configured schema, SSE, and WebSocket routes with real SDL downloads, text/event-stream payloads, and graphql-transport-ws connection_ack / next / complete frames instead of path-only reachability while also locking the additive shared-root story across multiple GraphQL modules — Shipped · GraphQL transport hosting tests 5/5 + targeted hosting regression 9/9 + package-surface tests 52/52

Sprint 31 follow-through

• ENG-069 event-dispatch runtime operator surfaces: host-agnostic event-dispatch runtime/state read contracts now live in Cephalon.Abstractions, /engine/snapshot now carries EventDispatchRuntimes plus EventDispatchStates, ASP.NET Core now exposes /engine/event-dispatch-runtimes and /engine/event-dispatches, Cephalon.Eventing.Wolverine now projects its managed loop through those routes truthfully, and the showcase sample now wires one optional Wolverine path end to end — Shipped
• ENG-070 outbox dispatch-ownership baseline: the engine now enriches OutboxDescriptor with a first-class DispatchPolicy, IOutboxDispatchPolicyCatalog now resolves disabled, consumer-managed, and runtime-managed ownership without leaking eventing internals into Cephalon.Engine, managed dispatch runtimes now declare explicit OutboxIds, and /engine/outboxes, /engine/event-dispatch-runtimes, /engine/event-dispatches, and the showcase sample now agree on the same execution owner truth — Shipped
• ENG-071 event-dispatch runtime summary and broader provider dispatch-store baseline: EventDispatchRuntimeDescriptor now carries a canonical aggregate Summary, runtime descriptors are live-enriched from reported dispatch state instead of leaving each consumer to re-aggregate that data ad hoc, the wolverine-adapter and shared eventing technology surfaces now reuse that same summary truth, and the MongoDB, Redis, Elasticsearch, and OpenSearch outbox packs now register IEventDispatchStore alongside their staged outboxes so the runtime-neutral managed-dispatch path is no longer limited to Entity Framework — Shipped
• ENG-072 graph/vector outbox dispatch-store follow-through: Cephalon.Data.Neo4j and Cephalon.Data.Qdrant now also register provider-native IEventDispatchStore implementations alongside their staged outboxes, the same outbox descriptors now resolve to consumer-managed when the eventing technology is active, and composition coverage now locks that graph/vector baseline explicitly while Cassandra, ClickHouse, and NATS remained tracked as separate storage-model follow-through work at that point — Shipped
• ENG-073 ledger outbox dispatch-store follow-through: Cephalon.Data.Nats now also registers a provider-native IEventDispatchStore implementation alongside its staged JetStream KV outbox, the same outbox descriptor now resolves to consumer-managed when the eventing technology is active, and composition coverage now locks that ledger-store baseline explicitly while Cassandra and ClickHouse remained tracked as separate storage-model follow-through work at that point — Shipped
• ENG-074 Cassandra provider-native event-dispatch store baseline: Cephalon.Data.Cassandra now also registers a provider-native IEventDispatchStore implementation alongside its staged LWT outbox, the pack now maintains a deterministic message-sharded outbox_pending_dispatch eligibility table so pending reads stay query-shaped without pretending Cassandra is a globally ordered queue, the cassandra-outbox descriptor now resolves to consumer-managed when the eventing technology is active, and composition coverage now locks that wide-column baseline explicitly while ClickHouse remains the one deliberate provider-specific dispatch-store gap — Shipped
• ENG-075 ClickHouse explicit unsupported dispatch-policy baseline: Cephalon.Data.ClickHouse now keeps its ReplacingMergeTree outbox staging-only by design, publishes DispatchPolicy.PolicyId = unsupported with ExecutionMode = disabled, and lets /engine/outboxes, event-dispatches, and snapshot.Outboxes report dispatchStore = unsupported / dispatchRuntime = unsupported plus provider-specific reason metadata instead of collapsing the pack to a generic “not configured” answer — Shipped

Sprint 38 follow-through

• ENG-086 database-role probe freshness policy: the engine-owned database runtime contract now exposes RoleProbeFreshnessSeconds, Cephalon.Data.EntityFramework now caches live role probes with explicit live-versus-cache metadata and migration-state invalidation, and the showcase sample now surfaces probe source, age, and freshness timing directly through its database-topology operator projection — Shipped · targeted composition tests 7/7 + hosting tests 3/3
• ENG-087 typed database-role probe contract and operator-surface follow-through: Cephalon.Abstractions now exposes DatabaseRoleProbeDescriptor, DatabaseRoleRuntimeDescriptor plus DatabaseRoleDescriptor now carry a typed Probe answer, Cephalon.Data.EntityFramework now projects stable cache/freshness/source timing through that shared contract while keeping metadata only for additive extras and compatibility, and the showcase sample now reads the typed probe surface directly in its projection/UI instead of parsing stable runtime-metadata keys locally — Shipped · targeted composition tests 25/25 + hosting tests 59/59 + package-surface tests 52/52
• ENG-088 engine-owned database-topology operational summary and advisory surface: Cephalon.Abstractions now exposes DatabaseTopologyOperationalAction, DatabaseTopologyOperationalActionPlan, DatabaseTopologyOperationalSummary, DatabaseTopologyOperationalAdvisory, DatabaseTopologyOperationalSnapshot, and IDatabaseTopologyOperationalSnapshotProvider, Cephalon.Engine now publishes /engine/database-topology plus snapshot.DatabaseTopology as the canonical posture answer over role health, migration status, production-guidance completeness, and ordered operator actions, and the showcase sample now consumes that engine-owned answer for readiness plus core advisories while keeping only read-model drift/backlog follow-through local — Shipped · targeted composition tests 3/3 + hosting tests 3/3 + package-surface tests 52/52
• ENG-089 database-topology action-plan showcase follow-through and contract truthfulness: the showcase sample now consumes the engine-owned action-plan contract as the baseline for ordered operator steps, preserves stable action categories plus source role and migration ids in its projection, browser console, and Markdown brief, and the docs/package-surface coverage now describe the shipped contract truthfully — Shipped · targeted composition tests 3/3 + hosting tests 3/3 + package-surface tests 52/52
• ENG-090 engine-owned database-migration playbook surface and showcase adoption: Cephalon.Abstractions now exposes ordered migration-playbook contracts, Cephalon.Engine now publishes /engine/database-migration-playbook plus snapshot.DatabaseMigrationPlaybook as the canonical ordered migration answer, and the showcase sample now consumes that engine-owned playbook directly while keeping only repo-root command adaptation plus sample-specific read-model follow-through local — Shipped · targeted composition tests 3/3 + hosting tests 4/4 + package-surface tests 52/52
• ENG-091 shared physical database migration coordination surface and showcase follow-through: the engine-owned database-role catalog now projects physical-target ids, display names, and physical co-location, the engine-owned migration playbook plus topology posture now surface shared-target coordination counts, per-step partner targets, and warning/action guidance when pending or failed logical migration work spans one physical database, and the showcase sample now consumes that engine-owned answer directly in /showcase, the Markdown brief, and the handoff package — Shipped · composition tests 4/4 + hosting tests 60/60 + package-surface tests 52/52
• ENG-092 shared physical database migration execution-group playbook follow-through: the engine-owned migration playbook now groups logical targets into physical-target execution batches with aggregate status, coverage counts, grouped migration ids, and shared-target coordination hints, and the showcase sample now consumes that engine-owned grouped answer directly in /showcase, the Markdown brief, and the handoff package — Shipped · composition tests 4/4 + hosting tests 60/60 + package-surface tests 52/52
• ENG-093 shared physical database migration execution-group command-set follow-through: the engine-owned migration playbook now also publishes grouped production and manual command sets per physical-target batch, and the showcase sample now consumes that engine-owned grouped command answer directly in /showcase, the Markdown brief, and the handoff package — Shipped · composition tests 4/4 + hosting tests 60/60 + package-surface tests 52/52
• ENG-094 shared physical database migration execution-group command-batch follow-through: the engine-owned migration playbook now also publishes combined production and manual command-batch templates per physical-target batch, and the showcase sample now consumes that engine-owned combined batch answer directly in /showcase, the Markdown brief, and the handoff package — Shipped · composition tests 4/4 + hosting tests 60/60 + package-surface tests 52/52
• ENG-095 phase 12 migration-pattern taxonomy baseline: the engine now ships strangler-fig plus backend-for-frontend as built-in architecture descriptors, and ASP.NET Core hosts now surface those phase 12 entries directly through /engine/patterns and the runtime app model while router/client-binding follow-through remains later — Shipped · composition tests 2/2 + hosting tests 1/1
• ENG-096 phase 12 strangler-fig runtime contract baseline: the engine now composes host-added and module-contributed migration routes through host-agnostic strangler-fig contracts, projects them into /engine/strangler-fig plus snapshot.StranglerFigRoutes, and exposes request resolution through /engine/strangler-fig/resolve while configuration-driven progress and host-level cutover remain later — Shipped · composition tests 2/2 + hosting tests 1/1 + package-surface tests 1/1

Sprint 39

• ENG-097 .NET 11 readiness baseline: the repo now ships scripts/validate-dotnet-readiness.ps1, validate-release.ps1 now uses the split test projects plus emits readiness artifacts, the release-validation workflow now includes a dedicated .NET 11 lane, and scaffolding now keeps net11.0 Dockerfile base images aligned with the requested target framework instead of freezing on 10.0 — Shipped · targeted tooling tests plus readiness-script contract coverage
• ENG-210 deployment-mode support contract baseline: the repo now ships scripts/deployment-mode-support.json, readiness reports now validate project-detected trim / Native AOT / single-file posture against that manifest, and the support docs now keep the same manifest-backed statement aligned across readiness, compatibility, and package-publishing guidance — Shipped · focused readiness and documentation coverage
• ENG-211 doctor support-contract follow-through baseline: Cephalon.Cli now packages that same deployment-mode support manifest, cephalon doctor now echoes the stable 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, and the adoption docs plus CLI/template-pack readmes now stay aligned with that CLI-surfaced support-contract story — Shipped · focused CLI and documentation coverage
• ENG-212 generated app doctor support-contract follow-through baseline: cephalon doctor --app-root <path> now carries that same packaged support contract into generated-app validation by comparing the scaffolded host target framework against the stable net10.0 shipping floor plus the .NET 11 assessment-only readiness lane, reading effective PublishTrimmed, PublishAot, and PublishSingleFile settings from the generated host project plus publish profile, and keeping stable-floor, readiness-lane, unclaimed publish-mode, and out-of-contract posture visible from the same generated-app bootstrap doctor path — Shipped · focused CLI and documentation coverage
• ENG-213 generated app doctor deployment-asset alignment baseline: 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/runtime base-image tags against the generated host target framework baseline, and keeps stable-floor versus readiness-lane deployment-asset posture visible from the same generated-app bootstrap doctor path before container deployment work begins — Shipped · focused CLI and documentation coverage
• ENG-214 generated app doctor self-hosted and hosted deployment-asset alignment baseline: 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 from the same generated-app bootstrap doctor path before published-output deployment work begins — Shipped · focused CLI and documentation coverage
• ENG-215 generated app doctor local orchestration asset alignment baseline: cephalon doctor --app-root <path> now validates the shipped compose.yaml and otel-collector-config.yaml assets, compares the generated compose baseline against the shipped Dockerfile plus OTLP collector handoff, compares the generated collector config against health_check, otlp/http on 4318, and the debug-exporter pipelines, and keeps generated local orchestration posture visible from the same generated-app bootstrap doctor path before local docker compose up --build work begins — Shipped · focused CLI and documentation coverage
• ENG-216 generated app doctor documentation-surface config alignment baseline: cephalon doctor --app-root <path> now validates the generated Configurations/AddOpenApi.json and Configurations/AddReferenceDocs.json assets, compares AddOpenApi.json against an explicit OpenApi:Title, compares AddReferenceDocs.json against explicit hosted reference-doc enablement, route, directory, and default-document settings, and keeps /scalar plus optional hosted reference-doc posture visible from the same generated-app bootstrap doctor path before teams rely on those docs surfaces — Shipped · focused CLI and documentation coverage
• ENG-217 generated app doctor split-config alignment baseline: cephalon doctor --app-root <path> now validates the generated Configurations/AddEngine.*.json assets plus Configurations/Observability/Development.json, compares the scaffolded app-model, engine-feature, observability, localization, and development Serilog defaults against explicit split-config baselines, and keeps generated runtime plus docs plus telemetry configuration posture visible from the same generated-app bootstrap doctor path before teams rely on those defaults — Shipped · focused CLI and documentation coverage
• ENG-218 generated app doctor host-bootstrap alignment baseline: 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 from the same generated-app bootstrap doctor path before teams rely on edited startup code — Shipped · focused CLI and documentation coverage
• ENG-219 generated app doctor test-harness alignment baseline: cephalon doctor --app-root <path> now validates the generated test project plus scaffolded Architecture/CompositionSmokeTests.cs and Features/*BehaviorSpecifications.cs placeholders, compares starter composition smoke plus Given/When/Then seams against the shipped scaffold contract, and keeps generated starter-test posture visible from the same generated-app bootstrap doctor path before teams replace those files with real specs — Shipped · focused CLI and documentation coverage
• ENG-220 generated app doctor guidance-doc alignment baseline: cephalon doctor --app-root <path> now validates the generated root README.md, Configurations/README.md, and deploy/*/README.md guidance 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 from the same generated-app bootstrap doctor path before teams follow those docs literally — Shipped · focused CLI and documentation coverage
• ENG-221 generated app doctor local package-feed guidance alignment baseline: cephalon doctor --app-root <path> now validates the generated .cephalon/packages/README.md guidance asset, compares scaffolded local package-feed seeding plus shared-feed replacement instructions against the shipped doctor contract, and keeps generated package-bootstrap guidance visible from the same generated-app bootstrap doctor path before teams seed packages or replace the cephalon source — Shipped · focused CLI and documentation coverage
• ENG-222 generated app doctor container deployment-script alignment baseline: 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 scripts, 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 from the same generated-app bootstrap doctor path before teams run those shipped scripts literally — Shipped · focused CLI and documentation coverage
• ENG-223 generated app doctor Kubernetes manifest alignment baseline: 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 manifests, 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 from the same generated-app bootstrap doctor path before teams rely on those shipped manifests literally — Shipped · focused CLI and documentation coverage
• ENG-224 generated app doctor teardown-script and systemd environment alignment baseline: 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 seams against the shipped doctor contract, and keeps teardown plus service-manager environment posture visible from the same generated-app bootstrap doctor path before teams rely on those operational assets literally — Shipped · focused CLI and documentation coverage
• ENG-225 external cold-start generated-app adoption replay baseline: the repo now ships scripts/validate-generated-app-adoption.ps1 so the install -> doctor -> scaffold -> seed local packages -> doctor —app-root -> restore -> build -> run -> route-probe loop is replayable from a temporary workspace outside the repository, and publish-package-artifacts.ps1 now preserves an existing output README.md so generated local package-feed guidance survives package refreshes — Shipped · focused tooling coverage plus external cold-start replay script validation
• ENG-226 external cold-start template-pack adoption parity baseline: the repo now ships scripts/validate-template-pack-adoption.ps1 so the install -> dotnet new install Cephalon.TemplatePack -> dotnet new list cephalon -> doctor -> dotnet new cephalon-monolith -> seed local packages -> doctor —app-root -> restore -> build -> run -> route-probe loop is replayable from a temporary workspace outside the repository, cephalon doctor now honors CEPHALON_DOCTOR_TEMPLATE_HIVE for isolated template installs, and cephalon doctor --app-root now accepts template-pack project-root starters without forcing the CLI scaffold layout — Shipped · focused tooling coverage plus template-pack parity replay script validation
• ENG-227 external out-of-tree package parity replay baseline: the repo now ships scripts/validate-out-of-tree-package-adoption.ps1 so the temporary-feed install -> doctor -> scaffold -> seed local packages -> pack Cephalon.ReferenceModule.Operations -> cephalon package stage -> patch Engine:Discovery:PackageDirectories plus Engine:PackagePolicy and Engine:Trust -> doctor —app-root -> restore -> build -> run -> staged-package route and runtime-surface probe loop is replayable from a temporary workspace outside the repository — Shipped · focused tooling coverage plus out-of-tree package parity replay script validation
• ENG-228 external detached-signature and publisher/signer trust replay baseline: the repo now ships scripts/validate-signed-package-governance.ps1 so the temporary-feed install -> doctor -> scaffold -> seed local packages -> repack Cephalon.ReferenceModule.Operations with a deterministic detached signature -> cephalon package stage -> patch Engine:Discovery:PackageDirectories plus stricter Engine:PackagePolicy and Engine:Trust:TrustedSignaturePublicKeys -> doctor —app-root -> restore -> build -> run -> signed-package route and runtime-surface probe loop is replayable from a temporary workspace outside the repository, while the same script also proves a tampered signed package is denied when signature verification is required — Shipped · focused tooling coverage plus signed-governance replay script validation
• ENG-229 external certificate-chain detached-signature trust replay baseline: the repo now ships scripts/validate-signed-package-certificate-chain-governance.ps1, while scripts/validate-signed-package-governance.ps1 now supports CertificateChain trust mode so the temporary-feed install -> doctor -> scaffold -> seed local packages -> repack Cephalon.ReferenceModule.Operations with a deterministic detached signature -> cephalon package stage -> patch Engine:Discovery:PackageDirectories plus stricter Engine:PackagePolicy, Engine:Trust:TrustedSignatureCertificates, and Engine:Trust:TrustedSignatureCertificateAuthorities -> doctor —app-root -> restore -> build -> run -> signed-package route and runtime-surface probe loop is replayable from a temporary workspace outside the repository, while the same runtime surfaces now expose trusted-certificate-chain plus certificateThumbprint truth and a tampered signed package is still denied — Shipped · focused tooling coverage plus certificate-chain signed-governance replay script validation
• ENG-098 behavior-execution rate-limiting baseline: Cephalon.Abstractions now extends BehaviorExecutionResilienceSelection plus BehaviorExecutionResilienceOverrideSelection with rate-limiting inputs, Cephalon.Engine now binds and validates behavior-execution rate-limiting overrides, Cephalon.Behaviors now enforces shared execution rate limiting in the behavior-dispatch middleware while publishing truthful rate-limiting metadata through /engine/behavior-resilience plus snapshot.BehaviorResiliencePolicies, and Cephalon.Behaviors.Http now proves both REST 429 precedence paths: the host-owned ASP.NET Core limiter wins when both layers are active, while Engine:Resilience:RateLimiting:Overrides can disable the endpoint policy for a targeted behavior/transport pair so the behavior-owned 429 answer surfaces without breaking OpenAPI or runtime truth — Shipped · targeted composition tests 16/16 + hosting tests 8/8 + package-surface tests 153/153
• ENG-099 generic behavior HTTP transport-native rate-limit envelopes: Cephalon.Behaviors.Http now shares one limiter-fault mapper across REST, GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings so behavior-execution limiter rejections keep protocol-native error shapes with stable Cephalon codes plus 429 metadata instead of collapsing into generic transport failures, while the hosting coverage now proves each binding preserves that transport truth under behavior-owned rate limiting — Shipped · targeted hosting tests 13/13 + composition tests 28/28 + package-surface tests 153/153
• ENG-100 generic behavior HTTP transport-native timeout and circuit-breaker envelopes: Cephalon.Behaviors.Http now shares one resilience-fault mapper across REST, GraphQL HTTP, JSON-RPC, GraphQL-SSE, GraphQL-WS, SSE, and WebSocket bindings so behavior-execution timeout and open-circuit rejections keep protocol-native error shapes with stable Cephalon codes plus 503 metadata and optional retry-after timing instead of collapsing into generic transport failures, while the hosting coverage now proves each binding preserves that transport truth under behavior-owned timeout and circuit-breaker policy — Shipped · targeted hosting tests 25/25 + composition tests 28/28 + package-surface tests 153/153
• ENG-101 phase 12 strangler-fig migration policy and progress baseline: Cephalon.Abstractions now exposes IStranglerFigMigrationRuntimeCatalog plus StranglerFigMigrationRuntimeDescriptor, Cephalon.Engine now binds deterministic Engine:Migration:StranglerFig default plus per-route overlays into snapshot.StranglerFigRoutePolicies, and Cephalon.AspNetCore now exposes /engine/strangler-fig/runtime plus /engine/strangler-fig/runtime/{routeId} while host-level cutover remains later — Shipped · composition tests 4/4 + hosting tests 1/1 + package-surface tests 153/153
• ENG-102 phase 12 ASP.NET Core strangler-fig cutover runtime: Cephalon.AspNetCore now derives host cutover execution from IStranglerFigMigrationRuntimeCatalog, exposes /engine/strangler-fig/cutover plus /engine/strangler-fig/cutover/resolve, rewrites rooted local targets in-process, redirects or proxies absolute HTTP or HTTPS targets through Engine:Migration:StranglerFig:AspNetCore, and rejects unsupported selected endpoints truthfully with 502 while broader provider-specific ingress or edge automation remains later — Shipped · hosting tests 5/5 + composition tests 4/4 + package-surface tests 153/153
• ENG-131 phase 13 CDC execution ownership binding baseline: Cephalon.Abstractions now exposes CdcCaptureExecutionBindingDescriptor, CdcCaptureDescriptor plus CdcCaptureRuntimeState now carry ExecutionBinding, Cephalon.Data now resolves authored/requested/effective ownership deterministically while rejecting ambiguous competing runtime claims and scoping the shared pump to captures effectively owned by data-cdc-capture-pump, 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 CDC ownership views stay on the same truth — Shipped · GitHub issue #556 · composition tests 12/12 + hosting tests 1/1 + tooling tests 171/171 + reference docs publish script
• ENG-137 phase 13 edge-runtime cell traffic materializer baseline: Cephalon.Abstractions now exposes ICellTrafficAutomationEdgeMaterializer plus generic CellTrafficAutomationMaterializationResult and CellTrafficAutomationMaterializationStates contracts, Cephalon.Engine now keeps deterministic build-time validation while reconciling edge-managed automation back onto the shared runtime catalog through a startup hosted service, and Cephalon.Edge now contributes the first concrete edge-runtime-materializer so the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface expose selected edge materializer ownership plus latest reconciliation posture without inventing a second traffic-materialization registry — Shipped · GitHub issue #564 · composition tests 6/6 + hosting tests 1/1 + tooling tests 175/175 + reference docs publish script
• ENG-139 phase 13 Kubernetes Gateway API control-plane materializer PoC: Cephalon.Edge.KubernetesGateway now contributes the first provider-specific control-plane pack over the shared traffic-materializer seam, projecting deterministic Gateway plus HTTPRoute intent through AddKubernetesGatewayTrafficMaterializer(...), provider-managed runtime metadata, and the kubernetes-gateway-traffic-materializations technology surface while keeping selected materializer ownership and overall automation truth on the existing /engine/cell-traffic-automations* and snapshot.CellTrafficAutomations surfaces — Shipped · GitHub issue #566 · composition tests 2/2 + hosting tests 1/1 + tooling tests 176/176 + reference docs publish script
• ENG-140 phase 13 Kubernetes Gateway live reconciliation baseline: Cephalon.Abstractions now exposes ICellTrafficAutomationMaterializationReportSink, Cephalon.Engine now lets provider and edge observers merge live materialization posture back into the shared automation catalog, and Cephalon.Edge.KubernetesGateway now adds opt-in observe-only Gateway plus HTTPRoute polling so the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations surface publish live condition, drift, and freshness truth without inventing a second control-plane registry — Shipped · GitHub issue #567 · composition tests 4/4 + hosting tests 2/2 + tooling tests 176/176 + reference docs publish script
• ENG-141 phase 13 Kubernetes Gateway apply-and-reconcile baseline: Cephalon.Edge.KubernetesGateway now adds apply-and-reconcile control-plane mode, keeps configured intent truthfully pending, applies only owned HTTPRoute resources while treating Gateway as a pre-provisioned dependency, and merges ownership-aware write results together with observed Gateway plus HTTPRoute status back into the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and kubernetes-gateway-traffic-materializations surfaces without inventing a second control-plane registry — Shipped · GitHub issue #568 · composition tests 6/6 + hosting tests 3/3 + tooling tests 176/176 + reference docs publish script
• ENG-142 phase 13 Traefik IngressRoute control-plane materializer baseline: Cephalon.Edge.Traefik now contributes the second provider-specific control-plane pack over the shared traffic-materializer seam, projecting deterministic Traefik IngressRoute intent through AddTraefikTrafficMaterializer(...), middleware plus TLS metadata, and the traefik-ingressroute-traffic-materializations technology surface while keeping selected materializer ownership and overall automation truth on the existing /engine/cell-traffic-automations* and snapshot.CellTrafficAutomations surfaces — Shipped · GitHub issue #569 · composition tests 2/2 + hosting tests 1/1 + tooling tests 180/180 + reference docs publish script
• ENG-143 phase 13 control-plane ownership lifecycle hardening baseline: Cephalon.Abstractions now exposes shared ownership/dependency/drift/lifecycle-action constants, Cephalon.Engine now derives normalized lifecycle summaries back onto the existing cell traffic automation catalog, and Cephalon.Edge, Cephalon.Edge.KubernetesGateway, plus Cephalon.Edge.Traefik now publish the same lifecycle vocabulary on the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces without inventing provider-local lifecycle registries — Shipped · GitHub issue #570 · composition tests 16/16 + hosting tests 5/5 + tooling tests 177/177 + reference docs publish script
• ENG-144 phase 13 Traefik live observation baseline: Cephalon.Edge.Traefik now adds TraefikTrafficObservationModes, TraefikTrafficObservationOptions, and opt-in observe-only polling over Traefik IngressRoute, Middleware, TLSOption, backend Service, and TLS Secret resources so the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations surfaces can publish live route existence, ownership, dependency, drift, and freshness truth without inventing a second control-plane registry — Shipped · GitHub issue #571 · composition tests 4/4 + hosting tests 2/2 + tooling tests 177/177 + reference docs publish script
• ENG-145 phase 13 Traefik apply-and-reconcile baseline: Cephalon.Edge.Traefik now adds apply-and-reconcile control-plane mode, keeps configured intent truthfully pending, creates or replaces only owned IngressRoute resources while treating Middleware, TLSOption, backend Service, and TLS Secret resources as pre-provisioned dependencies, and merges ownership-aware ingressRouteWriteAction metadata together with observed live Traefik posture back into the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and traefik-ingressroute-traffic-materializations surfaces without inventing a second control-plane registry — Shipped · GitHub issue #572 · composition tests 6/6 + hosting tests 3/3 + tooling tests 177/177 + reference docs publish script
• ENG-146 phase 13 provider-native lifecycle execution hardening baseline: Cephalon.Edge.KubernetesGateway and Cephalon.Edge.Traefik now distinguish external unmanaged resources from orphaned transfer candidates, lazily resolve active owners through the shared traffic catalog, preserve previous-owner metadata during transfer-aware adoption, and keep merged providerMaterialization.lifecycleAction truth on the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces instead of collapsing every successful reconciliation back to observe — Shipped · GitHub issue #573 · composition tests 16/16 + hosting tests 6/6 + tooling tests 177/177 + reference docs publish script
• ENG-147 phase 13 provider-native cleanup sweep execution baseline: Cephalon.Edge.KubernetesGateway and Cephalon.Edge.Traefik now expose opt-in EnableCleanupSweep, run namespace-scoped delete or prune sweeps over stale transferred or orphaned provider-owned routes only during apply-and-reconcile, and publish additive providerMaterialization.cleanup* plus provider-surface cleanup summaries on the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and provider-specific technology surfaces without inventing a second lifecycle registry — Shipped · GitHub issue #574 · composition tests 22/22 + hosting tests 8/8 + tooling tests 177/177 + reference docs publish script
• ENG-148 phase 13 SQL Server provider-native CDC runner baseline: Cephalon.Data.SqlServer now contributes AddSqlServerData(...), SqlServerCdcCaptureOptions, sqlserver-cdc-capture-flow, sqlserver-cdc-capture-pump, durable startLsn|seqval|operation checkpoints, and the same shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces so the CDC runtime model is now proven across both document and relational providers without inventing a second relational registry — Shipped · GitHub issue #576 · composition tests 17/17 + hosting tests 1/1 + tooling tests 179/179 + reference docs publish script
• ENG-149 phase 13 external CDC runtime reporting hardening baseline: CdcCaptureRuntimeObservation now carries stable ReportId, declared execution runtimes can now set ObservationStaleAfterSeconds plus RejectOutOfOrderReports, Cephalon.Data now treats matching duplicate report ids as idempotent retries while rejecting configured out-of-order submissions, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now publish LastReportId plus typed ObservationFreshness without inventing a second watchdog registry — Shipped · GitHub issue #578 · composition tests 19/19 + hosting tests 4/4 + tooling tests 179/179 + reference docs publish script
• ENG-153 phase 13 PostgreSQL provider-native CDC runner baseline: Cephalon.Data.Postgres now contributes AddPostgresData(...), PostgresLogicalReplicationCaptureOptions, postgresql-logical-replication-capture-flow, postgresql-logical-replication-capture-pump, publication/table validation, optional slot creation, durable slotName|commitLsn|transactionEndLsn checkpoints, and the same shared /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot surfaces so the CDC runtime model is now proven across document, relational change-table, and relational logical-replication sources without inventing a PostgreSQL-specific registry — Shipped · GitHub issue #582 · composition tests 22/22 + hosting tests 1/1 + tooling tests 181/181 + reference docs publish script
• ENG-154 phase 13 PostgreSQL publication and slot lifecycle hardening baseline: Cephalon.Data.Postgres now exposes RecreateSlotIfInvalidated, validates publication/table plus slot type/plugin/database ownership, reports additive slotLifecycleState, slotLifecycleAction, slotResumeMode, slotRestartLsn, slotConfirmedFlushLsn, slotWalStatus, and slotInvalidationReason on the shared CDC runtime story, and can intentionally recreate inactive invalidated slots without inventing a PostgreSQL-only lifecycle registry — Shipped · GitHub issue #584 · composition tests 23/23 + hosting tests 2/2 + tooling tests 181/181 + reference docs publish script
• ENG-150 phase 13 richer provider-native condition semantics baseline: Cephalon.Abstractions now ships CellTrafficAutomationMaterializationConditionDescriptor plus stable condition dimensions/categories/states/severities, provider and edge materialization results now carry typed Conditions, CellTrafficAutomationRuntimeDescriptor now carries merged MaterializationConditions, Cephalon.Engine now derives additive materialization.*, providerMaterialization.*, and edgeMaterialization.* summaries such as conditionCount, conditionBreakdown, and highestConditionSeverity, and Cephalon.Edge, Cephalon.Edge.KubernetesGateway, plus Cephalon.Edge.Traefik now publish stable readiness, ownership, dependency, lifecycle, and observation conditions on the existing shared plus provider-specific surfaces instead of provider-local condition vocabularies — Shipped · GitHub issue #579 · composition tests 30/30 + hosting tests 9/9 + tooling tests 179/179 + reference docs publish script
• ENG-152 phase 13 deeper external and edge-aware CDC execution topologies baseline: CdcCaptureRuntimeObservation and CdcCaptureExecutionReport now carry stable ReporterId plus EdgeNodeId, declared execution runtimes can now set ReporterLeaseSeconds, RejectConflictingReporterIds, and EdgeNodeIds, Cephalon.Data now enforces active reporter-lease ownership plus declared edge-node allow-lists while stamping reporter/edge metadata, and the same /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot surfaces now publish LastReporterId, ActiveReporterId, ReporterLeaseExpiresAtUtc, ObservedEdgeNodeIds, and LastEdgeNodeId without inventing a second topology coordinator — Shipped · GitHub issue #581 · composition tests 21/21 + hosting tests 5/5 + tooling tests 179/179 + reference docs publish script
• ENG-138 phase 13 richer multi-provider cell traffic reconciliation baseline: Cephalon.Abstractions now extends provider and edge materializer contracts with Priority plus provider-side CanMaterialize(...), Cephalon.Engine now resolves highest-priority matching materializers while deriving shared materializationState plus selection-rationale metadata on the existing traffic catalog, and the same /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface now publish requested, selected, and observed truth without inventing a second reconciliation registry — Shipped · GitHub issue #565 · composition tests 7/7 + hosting tests 1/1 + tooling tests 175/175 + reference docs publish script
• ENG-136 phase 13 provider-managed cell traffic materializer baseline: Cephalon.Abstractions now exposes ICellTrafficAutomationProviderMaterializer plus typed provider-materialization result/state contracts, Cephalon.Engine now keeps deterministic build-time validation while reconciling provider-managed automation back onto the shared runtime catalog through a startup hosted service, and the existing /engine/cell-traffic-automations*, snapshot.CellTrafficAutomations, and cell-traffic-automations technology surface now expose selected materializer ownership plus latest reconciliation posture without inventing a second traffic-materialization registry — Shipped · GitHub issue #562 · composition tests 5/5 + hosting tests 1/1 + tooling tests 253/253 + reference docs publish script
• ENG-135 phase 13 provider and edge-aware cell traffic automation baseline: Cephalon.Abstractions now extends CellTrafficAutomationRuntimeDescriptor plus ICellTrafficAutomationRuntimeCatalog with first-class providerId plus edgeNodeIds and provider/edge drill-down lookups, Cephalon.Engine now binds additive provider and edge targeting through Engine:Cells:TrafficAutomation while deriving provider-managed, edge-managed, and provider-and-edge-managed posture on the same runtime catalog, and Cephalon.AspNetCore now exposes /engine/cell-traffic-automations/providers/{providerId} plus /engine/cell-traffic-automations/edge-nodes/{edgeNodeId} so provider-aware and edge-aware automation stays on one truth — Shipped · GitHub issue #561 · composition tests 3/3 + hosting tests 1/1 + tooling tests 1/1 + reference docs publish script
• ENG-134 phase 13 external CDC runtime live-reporting baseline: Cephalon.Abstractions now ships CdcCaptureRuntimeObservation plus ICdcCaptureExecutionRuntimeReportSink, Cephalon.Data now adds opt-in DataRuntimeOptions.EnableExternalCdcRuntimeReporting with validated execution-runtime-owned report ingestion into the shared runtime-state catalog, and Cephalon.AspNetCore now maps POST /engine/cdc-capture-runtimes/{executionRuntimeId}/reports so out-of-process runners can refresh /engine/cdc-captures/runtime*, /engine/cdc-capture-runtimes*, and snapshot on the same truth — Shipped · GitHub issue #560 · composition tests 16/16 + hosting tests 3/3 + tooling tests 175/175 + reference docs publish script
• ENG-133 phase 13 first provider-native CDC runner PoC: Cephalon.Data.MongoDB now contributes MongoDB change-stream captures through MongoDbChangeStreamCaptureOptions, runs the provider-native hosted execution and execution runtime mongodb-change-stream-capture-pump, persists resume-token checkpoints only after linked outbox stage success, preserves authored sourceModuleId while surfacing contributorModuleId separately, and keeps /engine/cdc-*, /engine/execution-graphs, /engine/hosted-executions, and snapshot aligned on the same truth — Shipped · GitHub issue #559 · composition tests 15/15 + hosting tests 3/3 + tooling tests 174/174 + reference docs publish script
• ENG-132 phase 13 CDC external execution-runtime declaration baseline: Cephalon.Abstractions now promotes first-class execution-runtime ownership/topology fields plus inverse runtime lookups on the shared CDC catalogs, Cephalon.Data now accepts DataRuntimeOptions.CdcExecutionRuntimes declarations through CdcCaptureExecutionRuntimeOptions and keeps the shared pump scoped away from externally owned captures, and Cephalon.AspNetCore now keeps /engine/cdc-capture-runtimes*, inverse execution-runtime drill-down routes, and snapshot aligned for shared or configured external/provider-native runtimes without inventing a second registry — Shipped · GitHub issue #558 · composition tests 14/14 + hosting tests 2/2 + tooling tests 172/172 + reference docs publish script
• ENG-130 phase 13 CDC execution runtime catalog baseline: Cephalon.Abstractions now exposes CdcCaptureExecutionRuntimeDescriptor, CdcCaptureExecutionRuntimeSummary, and ICdcCaptureExecutionRuntimeCatalog, Cephalon.Data now contributes the shared data-cdc-capture-pump execution runtime with ownership/topology metadata plus an aggregate summary derived from shared CDC runtime state, 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 the existing per-capture CDC surfaces — Shipped · GitHub issue #555 · composition tests 9/9 + hosting tests 1/1 + tooling tests 3/3 + reference docs publish script
• ENG-129 phase 13 shared CDC acknowledgement and checkpoint-commit baseline: Cephalon.Abstractions now exposes CdcCaptureExecutionAcknowledgement plus ICdcCaptureAcknowledger, Cephalon.Data now lets the shared CDC pump acknowledge provider progress only after linked outbox staging succeeds, the shared runtime now reports acknowledgement plus acknowledgerServiceType metadata on success and failureKind = acknowledgement with pending checkpoint/change-id metadata on failure, and the data-cdc-capture-flow execution graph now includes acknowledge-cdc-progress so /engine/execution-graphs, /engine/hosted-executions, /engine/runtime-story, and /engine/snapshot stay aligned with the replay-safe loop — Shipped · GitHub issue #554 · composition tests 9/9 + hosting tests 1/1 + tooling tests 2/2
• ENG-128 phase 13 shared CDC hosted-execution substrate baseline: Cephalon.Abstractions now exposes 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, 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* — Shipped · GitHub issue #525 · composition tests 6/6 + hosting tests 1/1 + tooling tests 1/1
• ENG-127 phase 13 CDC freshness, lag, and publication posture baseline: Cephalon.Abstractions now exposes typed CDC freshness/lag/publication status contracts, Cephalon.Data now lets runtime reports carry those answers and applies a conservative linked-dispatch publication overlay, Cephalon.Engine now projects the richer snapshot.CdcCaptureStates, and Cephalon.AspNetCore now keeps /engine/cdc-captures/runtime* truthful with the same typed operational posture — Shipped · GitHub issue #524 · composition tests 1/1 + hosting tests 1/1 + tooling tests 1/1
• ENG-126 phase 13 CDC runtime-state and publish-state follow-through: Cephalon.Abstractions now exposes CdcCaptureRuntimeState plus ICdcCaptureRuntimeStateCatalog, Cephalon.Data now reports descriptor-backed runtime state with optional linked OutboxDispatchState, Cephalon.Engine now projects snapshot.CdcCaptureStates, and Cephalon.AspNetCore now exposes /engine/cdc-captures/runtime* so operators can inspect latest capture posture without a host-only monitor — Shipped · GitHub issue #523 · composition tests 1/1 + hosting tests 1/1 + tooling tests 1/1
• ENG-124 phase 13 data product runtime baseline: Cephalon.Abstractions now exposes IDataProduct<T> plus DataProductDescriptor, IDataProductCatalog, IDataProductContributor, and IDataProductRegistry, Cephalon.Engine now projects snapshot.DataProducts through the same engine-owned runtime truth, and Cephalon.AspNetCore now exposes /engine/data-products* so module-owned data mesh descriptors stay operator-readable without a host-only catalog — Shipped · GitHub issue #521 · composition tests 2/2 + hosting tests 1/1 + tooling tests 1/1
• ENG-125 phase 13 CDC capture runtime baseline: Cephalon.Abstractions now exposes ICdcCapture plus CdcCaptureDescriptor, ICdcCaptureCatalog, ICdcCaptureContributor, and ICdcCaptureRegistry, Cephalon.Engine now projects snapshot.CdcCaptures while validating source-module and outbox references through the same engine-owned runtime truth, and Cephalon.AspNetCore now exposes /engine/cdc-captures* so module-owned CDC descriptors stay operator-readable without a host-only sync registry — Shipped · GitHub issue #522 · composition tests 3/3 + hosting tests 1/1 + tooling tests 1/1
• ENG-123 phase 13 configuration-driven cell traffic automation baseline: Cephalon.Abstractions now exposes CellTrafficAutomationRuntimeDescriptor plus ICellTrafficAutomationRuntimeCatalog, Cephalon.Engine now binds Engine:Cells:TrafficAutomation into snapshot.CellTrafficAutomations plus the cell-traffic-automations technology runtime surface while deriving automation truth from the active route plus health-isolation graph, and Cephalon.AspNetCore now exposes /engine/cell-traffic-automations* so the same automation posture stays operator-readable without a host-only traffic manager — Shipped · GitHub issue #520 · composition tests 2/2 + hosting tests 1/1 + tooling tests 169/169
• ENG-122 phase 13 cell-health-isolation runtime baseline: Cephalon.Abstractions now exposes CellHealthIsolationDescriptor, ICellHealthIsolationContributor, ICellHealthIsolationRegistry, and ICellHealthIsolationCatalog, Cephalon.Engine now projects snapshot.CellHealthIsolations plus the cell-health-isolations technology runtime surface while validating source-module ownership against active cells, and Cephalon.AspNetCore now exposes /engine/cell-health-isolations* so the same health-isolation posture stays operator-readable without a host-only partition registry — Shipped · GitHub issue #519 · composition tests 2/2 + hosting tests 1/1 + tooling tests 168/168
• ENG-121 phase 13 cell-route runtime governance baseline: Cephalon.Abstractions now exposes CellRouteDescriptor, ICellRouteContributor, ICellRouteRegistry, and ICellRouteCatalog, Cephalon.Engine now projects snapshot.CellRoutes plus the cell-routes technology runtime surface while validating source-module ownership against active cells, and Cephalon.AspNetCore now exposes /engine/cell-routes* so the same governed route posture stays operator-readable without a host-only traffic registry — Shipped · GitHub issue #518 · composition tests 2/2 + hosting tests 1/1 + tooling tests 167/167
• ENG-120 phase 13 cell-boundary contract baseline: Cephalon.Abstractions now exposes CellBoundaryDescriptor, ICellBoundaryContributor, ICellBoundaryRegistry, and ICellBoundaryCatalog, Cephalon.Engine now projects snapshot.CellBoundaries plus the cell-boundaries technology runtime surface while auto-selecting cell-based-architecture for active boundaries, and Cephalon.AspNetCore now exposes /engine/cells* so the same topology stays operator-readable without a host-only registry — Shipped · GitHub issue #517 · composition tests 2/2 + hosting tests 1/1 + tooling tests 166/166
• ENG-119 phase 12 strangler-fig ingress runtime follow-through: Cephalon.Abstractions now exposes IStranglerFigIngressRuntimeCatalog plus StranglerFigIngressRuntimeDescriptor, Cephalon.Engine now projects snapshot.StranglerFigIngressRoutes, and Cephalon.AspNetCore now exposes /engine/strangler-fig/ingress* while deriving host cutover from that shared ingress truth and keeping provider-specific ingress or edge automation separate — Shipped · GitHub issue #516 · composition tests 5/5 + hosting tests 6/6 + tooling tests 171/171
• ENG-103 phase 12 backend-for-frontend client-binding runtime baseline: Cephalon.Abstractions now exposes host-agnostic BFF client-binding contracts, Cephalon.Engine now composes host-added, module-contributed, and Engine:BackendForFrontend:Bindings entries into snapshot.BackendForFrontendBindings while auto-selecting backend-for-frontend when bindings exist, and Cephalon.AspNetCore now exposes /engine/backend-for-frontend plus client/module/transport drill-down routes while client-aware filtering or materialization remain later — Shipped · composition tests 3/3 + hosting tests 1/1 + package-surface tests 1/1
• ENG-104 phase 12 backend-for-frontend client-aware REST filtering runtime baseline: Cephalon.Abstractions now exposes public client-aware BFF REST runtime contracts, Cephalon.AspNetCore now derives IBackendForFrontendRestRuntimeCatalog from the shared binding catalog plus published REST endpoint truth, /engine/snapshot now carries BackendForFrontendRestEndpoints, and /engine/backend-for-frontend/rest-endpoints now exposes binding/client/module/published-endpoint drill-down routes while per-client OpenAPI/Scalar materialization remains later — Shipped · hosting tests 1/1 + package-surface tests 2/2
• ENG-105 phase 12 backend-for-frontend REST document materialization baseline: Cephalon.Abstractions now exposes scope-specific BFF REST document contracts, Cephalon.AspNetCore now derives /engine/backend-for-frontend/rest-documents plus filtered binding/client OpenAPI and Scalar surfaces from the shared BFF REST runtime truth and host OpenAPI settings, and /engine/snapshot now carries BackendForFrontendRestDocuments — Shipped · hosting tests 2/2 + package-surface tests 2/2
• ENG-106 phase 12 feature-flag runtime baseline: Cephalon.Abstractions now exposes host-agnostic feature-flag contracts, Cephalon.Engine now composes code-first, configuration-driven, and module-contributed flags into IFeatureFlagRuntimeCatalog, IFeatureToggle, and snapshot.FeatureFlags, and Cephalon.AspNetCore now exposes /engine/features plus the shared evaluation route while the later generic provider bridge and any future capability publication remain separate follow-through — Shipped · composition tests 3/3 + hosting tests 1/1 + package-surface tests 1/1
• ENG-107 phase 12 feature-flag external-provider bridge baseline: Cephalon.Abstractions now exposes FeatureFlagProviderBindingDescriptor, FeatureFlagProviderEvaluationResult, and IFeatureFlagProvider; FeatureFlagDescriptor plus FeatureFlagEvaluationResult now carry typed provider bindings and provider-result details; Cephalon.Engine now binds Engine:Features:Flags:*:ProviderBindings, adds engine.AddFeatureFlagProvider(...), and lets registered providers further gate Cephalon-owned flags through the shared IFeatureToggle without replacing the runtime catalog; Cephalon.Behaviors.Http now keeps subject propagation aligned between REST and behavior-owned execution so provider-backed behavior gates can evaluate the same subject truth end-to-end — Shipped · composition tests 8/8 + hosting tests 6/6 + package-surface tests 157/157
• ENG-108 phase 12 saga choreography baseline: Cephalon.Abstractions now lets behaviors declare AsSagaChoreography() and carries the stable saga-choreography pattern id through source-generated topology literals; Cephalon.Behaviors.Patterns now exposes ISagaChoreographyPublisher, SagaChoreographyPublication, SagaChoreographyStepResult, InMemorySagaChoreographyPublisher, and ChoreographySagaExecutionStrategy so choreography steps can stage continuation or compensation publications through a host-agnostic contract; Cephalon.Behaviors now exposes capability behaviors.saga-choreography plus advisory ABT-005 when choreography steps omit outbox staging — Shipped · composition tests 64/64 + package-surface tests 157/157
• ENG-109 phase 12 durable execution baseline: Cephalon.Abstractions now lets behaviors declare AsDurableExecution() and carries the stable durable-execution pattern id through source-generated topology literals; Cephalon.Behaviors.Patterns now exposes IDurableExecution<TState>, IDurableExecution<TInput, TState, TOutput>, DurableExecutionState<TState>, DurableExecutionStepResult<TOutput>, and DurableExecutionStrategy so durable workflows can replay from IEventStore, validate sequential stream versions, append continuation events, and return 200 / 202 / 204 truthfully; Cephalon.Behaviors now exposes capability behaviors.durable-execution plus compatibility rule ABT-006, and Kafka/RabbitMQ/test behavior contexts now flow IEventStore into the shared pipeline for non-default-host execution — Shipped · composition tests 112/112 + package-surface tests 157/157
• ENG-110 phase 12 explicit saga choreography eventing bridge baseline: Cephalon.Eventing.Behaviors now exposes AddBehaviorEventingBridge() as the explicit companion-pack bridge that swaps the fallback in-memory choreography publisher for an outbox-backed eventing handoff when EventDrivenIntegration, publishing, and a real IOutbox are all active; the bridge preserves explicit ISagaChoreographyPublisher overrides, projects capability eventing.behaviors.saga-choreography plus the saga-choreography-bridges runtime surface, and keeps choreography ownership in Cephalon.Behaviors.Patterns instead of collapsing it into the Cephalon.Eventing baseline — Shipped · targeted composition tests 25/25 + tooling tests 236/236
• ENG-111 phase 12 durable execution runtime catalog baseline: Cephalon.Abstractions now exposes DurableExecutionRuntimeDescriptor plus IDurableExecutionRuntimeCatalog, Cephalon.Behaviors.Patterns now derives the catalog from shared durable behavior topology plus registered implementation types, Cephalon.Engine now projects snapshot.DurableExecutions, and Cephalon.AspNetCore now exposes /engine/durable-executions plus behavior/module/transport drill-down routes while replay-progress and failure-posture follow-through remain later — Shipped · composition tests 1/1 + hosting tests 1/1 + package-surface tests 158/158
• ENG-112 phase 12 durable execution runtime state and failure-posture baseline: Cephalon.Abstractions now exposes DurableExecutionRuntimeState plus IDurableExecutionRuntimeStateCatalog, Cephalon.Behaviors.Patterns now reports per-stream durable observations from DurableExecutionStrategy, Cephalon.Engine now projects snapshot.DurableExecutionStates, and Cephalon.AspNetCore now exposes /engine/durable-executions/runtime plus stream/behavior/module/transport drill-down routes while higher-level timers/signals/compensation helpers remain later — Shipped · composition tests 2/2 + hosting tests 2/2 + package-surface tests 158/158
• ENG-113 phase 12 durable execution timers and signals coordination baseline: Cephalon.Abstractions now exposes DurableExecutionPendingTimer plus DurableExecutionPendingSignal, Cephalon.Behaviors.Patterns now lets DurableExecutionStepResult<TOutput> and DurableExecutionStrategy surface durable waiting posture plus pending timer/signal coordination through the shared runtime state catalog, and Cephalon.AspNetCore now exposes /engine/durable-executions/runtime/timers* plus /engine/durable-executions/runtime/signals* while compensation helpers remain later — Shipped · GitHub issue #510 · composition tests 2/2 + hosting tests 2/2 + package-surface tests 161/161
• ENG-114 phase 12 durable execution compensation helper baseline: Cephalon.Abstractions now exposes DurableExecutionCompensationAction, Cephalon.Behaviors.Patterns now lets DurableExecutionStepResult<TOutput> and the shared durable runtime-state catalog surface operator-facing compensation actions without changing coordination semantics, and Cephalon.AspNetCore now exposes /engine/durable-executions/runtime/compensations* while any future auto-executing durable recovery remains later — Shipped · GitHub issue #511 · composition tests 7/7 + hosting tests 2/2 + package-surface tests 161/161
• ENG-115 phase 12 saga choreography authoring helper baseline: Cephalon.Behaviors.Patterns now exposes ISagaChoreographyStepResult, ISagaEventReactor<TEvent>, ISagaEventReactor<TEvent, TOutput>, SagaChoreographyStepResult<TOutput>, and typed JSON helper factories on SagaChoreographyPublication, while ChoreographySagaExecutionStrategy now normalizes the shared result contract without changing the explicit ISagaChoreographyPublisher handoff or the opt-in Cephalon.Eventing.Behaviors bridge — Shipped · GitHub issue #512 · composition tests 41/41 + tooling tests 188/188 + reference docs publish script
• ENG-116 phase 12 saga choreography runtime catalog baseline: Cephalon.Abstractions now exposes SagaChoreographyRuntimeDescriptor plus ISagaChoreographyRuntimeCatalog, Cephalon.Behaviors.Patterns now derives the catalog from shared choreography behavior topology plus registered implementation types, Cephalon.Engine now projects snapshot.SagaChoreographies, and Cephalon.AspNetCore now exposes /engine/saga-choreographies plus behavior/module/transport drill-down routes while live publication-state tracking remains later — Shipped · GitHub issue #513 · composition tests 1/1 + hosting tests 1/1 + package-surface tests 163/163
• ENG-117 phase 12 saga choreography live publication-state baseline: Cephalon.Abstractions now exposes SagaChoreographyPublicationRuntimeState plus ISagaChoreographyPublicationRuntimeStateCatalog, ChoreographySagaExecutionStrategy now reports accepted and failed publication handoff observations directly from the shared choreography path, Cephalon.Engine now projects snapshot.SagaChoreographyPublicationStates, and Cephalon.AspNetCore now exposes /engine/saga-choreographies/runtime* operator routes for publication, behavior, module, transport, channel, correlation, compensation, and failure drill-downs while eventing-bridge and downstream dispatch truth remain separate — Shipped · GitHub issue #514 · composition tests 8/8 + hosting tests 2/2 + tooling tests 190/190 + reference docs publish script
• ENG-118 phase 12 saga choreography capability-publication follow-through: Cephalon.Behaviors now publishes behaviors.saga-choreography.runtime-catalog and behaviors.saga-choreography.publication-state only when AddBehaviorPatterns() activates the shared choreography runtime services, /engine/capabilities now exposes pack/service/snapshot/route ownership truth for those surfaces, and the explicit eventing.behaviors.saga-choreography bridge capability remains separate durable-handoff truth — Shipped · GitHub issue #515 · composition tests 7/7 + hosting tests 2/2 + tooling tests 190/190