Generate a production‑grade Rust workspace that implements an autonomous, multi‑agent Test‑Driven Development machine for code katas. The tool must run locally as a CLI, orchestrate three agents (tester, implementor, refactorer), and follow a strict red‑green‑refactor loop for a configurable number of steps. It must store state in git and allow each agent to read the last commit message, the last git diff, and the entire working tree.

• Create a Rust workspace with clean boundaries, strong types, and testable modules.
• Implement an orchestrator that cycles over agents: tester → implementor → refactorer → implementor → … for N steps.
• Each agent must run tests and compile checks, and must be able to edit the codebase across multiple files and modules.
• Persist progress via conventional commits. Commit messages must include all context needed by the next agent.
• Consume a kata description from a Markdown file. Agents should align their actions to that document.
• Support pluggable LLMs throu

Talking about chapter 6, I want to add a question on the part where the author states "of course, we could add special runtime validation checks to make sure that this couldn’t happen."

The question is: Aren’t the check pushed to the edge of the system? Somewhere there will be logic for deciding if we want to create a EmailContactInfo, PostalContactInfo or BothContactMethods. Shouldn’t this logic be (unit) tested?

For sure the logic for deciding whether to create an EmailContactInfo, PostalContactInfo, or BothContactMethods does need to be implemented somewhere! In fact, this decision-making logic—let's call it the "creation logic"—becomes the entry point where the business rule is enforced. Here's how that ties into the points raised in the book and your question:

Scott Wlaschin advocates for embedding business rules directly in th

One thing I’m getting by reading chapter 6 is that we typically create very few types for describing and modeling a business domain, while one of the key learnings I got from this chapter that we should aggressively create types to capture differences and nuances, and to properly describe the different states of business workflows. (e.g. not an EmailAddress but a UnverifiedEmailAddress and a VerifiedEmailAddress)

Chapter 6 is all about using types as a way to explicitly model and describe the domain in a precise and meaningful way. This means creating types to capture subtle differences and distinctions in your domain that are often overlooked when using a less type-focused approach.

So, yes, we should aggressively create types when modeling a business domain. This isn’t about creating types for the sake of complexity but rather about creating types to represent the real-world states and constraints of your business workflows in a clear, unambiguous way. This helps make your code more expres

Here are some practical exercises we could do:

Think about a real-world system you're familiar with (e.g., a shopping cart, a library management system, a flight booking system). For each one:

• List out the core entities in the domain.
• Identify the key business rules (invariants) that must always hold true.
• Ask yourself: How would you model these rules as types and functions?

In chapter 5, p.95, Scott writes:

"First, is Order an Entity or a Value Object? Obviously it’s an Entity—the details of the order may change over time, but it’s the same order.

What about an OrderLine, though? If we change the quantity of a particular order line, for example, is it still the same order line? In most designs, it would make sense to say yes, it is still the same order line, even though the quantity or price has changed over time. So OrderLine is an Entity too, with its own identifier.

But now here’s a question: if you change an order line, have you also changed the order that it belongs to?

In this case, it’s clear that the answer is yes: changing a line also changes the entire order. In fact, having immutable data structures makes this unavoidable. If I have an immutable Order containing immutable OrderLines, then just making a copy of one of the order lines does not also make a copy of the Order as well. In order to make a change to an OrderLine contained in an Order, I need to make the c

The responsibility for creating unique identifiers (keys) for entities in a domain-driven design (DDD) system depends on the context and requirements of the application. There are several common approaches to generating these identifiers, each suited to specific use cases. Let’s explore these approaches and who is responsible for generating the identifiers in each case.

In some domains, the identifier is inherent to the entity itself and comes from the real-world domain.

Examples:

• Serial numbers for banknotes: In the state mint context, the identifier (serial number) is usually assigned during the manufacturing process. The mint’s production system generates the serial number and ensures uniqueness.