AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
翻譯準備中
Supercharged .NET server side development!
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
Wolverine
======
Wolverine is a Next Generation .NET Mediator and Message Bus. Check out
the documentation website at https://wolverinefx.net/.
While Wolverine is open source, JasperFx Software offers paid support and consulting contracts
for Wolverine.
Help us keep working on this project 💚
To work with the code, just open the wolverine.sln file in the root of the repository and go. If you want to run
integration tests though, you'll want Docker installed locally
and to start the matching testing services with:檢視完整 README ↗Wolverine is a Next Generation .NET Mediator and Message Bus. Check out the documentation website at https://wolverinefx.net/.
While Wolverine is open source, JasperFx Software offers paid support and consulting contracts for Wolverine.
To work with the code, just open the wolverine.slnx file in the root of the repository and go. There's also
wolverine_slim.slnx, a lighter variant that omits several extension projects, and wolverine_fsharp.slnx. CI builds
the full wolverine.slnx, so build that one before pushing:
dotnet build wolverine.slnx -c Release -f net9.0
If you want to run integration tests, you'll want Docker installed locally and to start the matching testing services with:
docker compose up -d
That covers Azure Service Bus too — it runs against the Azure Service Bus emulator, so no cloud subscription is needed. See the Azure Service Bus tests README for the ports it uses and why there are two emulator instances.
This repository follows a major-line branching strategy:
main — Active development for the Wolverine 6.x line, which is generally available and shipping regular releases. Day-to-day work, new features, the cold-start / runtime-perf pass and the AOT pillar all land here. See the migration guide for the at-a-glance table of changed defaults / removed APIs / moved namespaces from 5.x.5.0 — Maintenance branch for the Wolverine 5.x line, branched from the V5.39.0 tag. Receives bug fixes only — no new features and no breaking changes. Patch releases off the 5.x line ship from this branch.archive/cloudevents-attempt-2025 — Preserved, abandoned. An incomplete CloudEvents-for-SQS-and-SNS feature branch from August 2025 that never merged. Kept for historical reference only.Older release-specific branches (e.g., 4.0, release/5.30, 5.36) exist for in-flight or completed work on prior versions and are not active development surfaces. New contributions should target main. Backport candidates for the 5.x line can be opened against 5.0 after the corresponding PR has merged to main.
For contributors, there's a light naming style Jeremy refuses to let go of that he's used for gulp 20+ years. The thing to internalize is that casing follows accessibility, not member kind:
_ as a prefix for private fieldsSo a single class routinely mixes both, and that's intentional:
public class SqlServerQueue
{
private readonly SqlServerTransport _parent;
public Task SendAsync(Envelope envelope) { ... } // public -> Pascal
private void buildSenderIfMissing() { ... } // private -> camel
}
If you're coming from a codebase that Pascal cases every method regardless, rule 2 is the one that will catch you
out. These rules are encoded in .editorconfig, so your IDE will flag new violations as you type.
They surface in the IDE and in dotnet format, but never fail the build — there's a fair amount of pre-existing
drift, and renaming a protected member is a breaking change for anyone subclassing it, so please don't mass-fix
what's already there.
CHANGELOG.mdPlease leave CHANGELOG.md alone in a pull request. Every concurrent branch appends to the same "Unreleased"
section, so every one of them conflicts with every other on merge. The PR description and the commit message are
where a change explains itself, and both are attached to the work forever. Release notes are a release-time job.
The build is scripted out with Nuke in the /build folder. To run the
build file locally, use build with Windows or ./build.sh on OSX or Linux.
All the documentation content is in the /docs folder. The documentation is built and published
with Vitepress and
uses Markdown Snippets for code samples. To run the documentation
locally, you'll need a recent version of Node.js installed. To start the documentation website, first run:
npm install
Then start the actual website with:
npm run docs
To update the code sample snippets, use:
npm run mdsnippets
This is a little sad, but Wolverine started as a project named "Jasper" way, way back in 2015 as an intended reboot of an even older project named FubuMVC / FubuTransportation that was a combination web api framework and asynchronous message bus. What is now Wolverine was meant to build upon what we thought was the positive aspects of fubu's programming model but do so with a much more efficient runtime. Wolverine was largely rebooted, revamped, and renamed in 2022 with the intention of being combined with Marten into the "critter stack" for highly productive and highly performant server side development in .NET.