---
title: Explanation
description: Why rtb-forge is shaped the way it is — one crate with two slices, link-time backend registration, a mixed gix/git backend, and what it deliberately does not do.
tags: [explanation]
---
# Explanation
Background and reasoning. Nothing here is needed to use the crate; it is here so
that when the crate behaves in a way you did not expect, you can tell whether
that is a decision or a defect.
| [Why release providers and git operations share one crate](01-two-slices-one-crate.md) | What the two slices are, and why they are not two crates |
| [Why backends register themselves at link time](02-link-time-registration.md) | What `linkme` buys, and what it costs |
| [Why the write paths shell out to git](03-why-write-paths-shell-out.md) | Where the "pure Rust git" claim stops being true |
| [What rtb-forge does not do](04-what-this-does-not-do.md) | The limits, stated as limits |
## Where the design decisions are recorded
The original design records live in the rust-tool-base monorepo as
point-in-time specs. They are not documentation and they are not maintained
alongside the code — where a spec and this crate disagree, the crate is right.
These pages restate the reasoning in their own words so you do not have to read
a spec to understand the code.