berkaroad/Eventual2PC

Eventual2PC is a .NET-based distributed transaction framework designed to coordinate multi-aggregate root interactions using two-phase commit (2PC) and TCC patterns. It provides the core abstractions for transaction initiators and participants, along with domain events and command interfaces to manage pre-commit, commit, and rollback states. The system is structured as a reusable library, packaged as a NuGet package for integration into larger applications.

The repository is initialized with the core structure for the Eventual2PC library, including a .NET project, a Makefile for building and packing the NuGet package, and a comprehensive README documenting the 2PC/TCC patterns, domain terminology, and processing flows. This establishes the baseline for a distributed transaction framework supporting multi-aggregate root interactions.

(repo-wide) · high confidence

The Eventual2PC module is introduced, providing the foundational interfaces and classes for a two-phase commit (2PC) transaction system. This includes the core abstractions for transaction initiators and participants, along with a comprehensive set of domain events (such as pre-commit success/failure, commit, and rollback events) and corresponding command interfaces to facilitate distributed transaction coordination.

src/Eventual2PC · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 46 → 46 (+0.0)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (+0.0)
• Architecture 69 → 69 (+0.0)
• Maturity 54 → 54 (+0.0)
• Readiness 24 → 24 (+0.0)
• Security 100 → 100 (+0.0)
• Performance 70 → 70 (+0.0)

• Inconsistent property naming for the 'PreCommitFailedParticipantAdded' event. It uses 'TransactionType' and 'TransactionId', but 'TransactionParticipant' for the participant. This is consistent with 'PreCommitSucceedParticipantAdded', but inconsistent with 'CommittedParticipantAdded' which also uses 'TransactionParticipant'. However, the real inconsistency is that 'TransactionParticipant' is used for a single participant, while 'TransactionParticipants' is used for a collection in 'ITransactionInitiatorAllParticipantPreCommitSucceed'.
• No exposed public API
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• single-maintainer — knowledge-concentration (bus factor) risk

• Inconsistent naming for the collection of participants. One property is named PreCommitSucceedTransactionParticipants (specific to the success state) while the other is simply TransactionParticipants. Given that ITransactionInitiatorAllParticipantPreCommitSucceed specifically deals with the 'Succeed' state, the property name should likely be consistent with the specific state or follow a uniform pattern (e.g., both TransactionParticipants or both PreCommitSucceedTransactionParticipants).
• The concept of a participant pre-committing successfully is named 'PreCommitFailed' in one method and 'PreCommitSuccess' in another. While 'Failed' and 'Success' are antonyms, the inconsistency lies in the fact that the corresponding event types and commands use 'PreCommitSucceed' (e.g., ITransactionInitiatorAllParticipantPreCommitSucceed, ITransactionInitiatorAddPreCommitSucceedParticipantCommand) rather than 'PreCommitSuccess'. The method AddPreCommitSuccessParticipant uses 'Success' (noun/adjective) while the rest of the codebase uses 'Succeed' (verb/participle) for the same logical state.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

berkaroad/Eventual2PC was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.