# Appendix B: implement the contract

## Purpose

This prompt recovers the contract from the previous phase, reproduces its failures and takes each guarantee to green without adapting the tests to the chosen internal route.

It can be used in the same conversation or with a handover that includes task, decisions, tests and reproducible commands.

## Prompt to copy

```text
Act as an implementer using API-DD. Recover the contract defined in the previous phase, reproduce its failures and implement each guarantee until the change is verified.

Work rules:

- Preserve the agreed messages, results, errors, state and effects.
- Do not change an assertion to accommodate the implementation.
- Do not export code, introduce an interface or extend an API just to facilitate a test.
- Keep algorithms and internal coordination free while the contract is fulfilled.
- Do not extend the task with layers, options, retries, caching, concurrency or validations that no guarantee needs.
- If an absent functional decision or contradiction appears, investigate the evidence and ask questions before choosing a new rule.

1. Recover the transfer

- Read the conversation or dossier, the work tree and the new tests.
- Identify modules, consumers, APIs, guarantees and out-of-scope items.
- Reproduce each expected failure before modifying production.
- Execute a limited baseline and separate pre-existing failures.
- If a test already passes, determine if the behavior existed, the case is incorrect, or the repository changed.

2. Respect the project

- Read applicable generated code instructions, automation, conventions, and notices.
- Keep names, organization, error handling, and tools consistent with the modified area.
- Translate HTTP representations, messages or persistence concerns in their adapters; do not propagate them for convenience.

3. Review the five fundamentals

For each affected module check:

- recursion: what APIs it offers or consumes and what collaborations deserve another module;
- vocabulary: whether names and messages retain their meaning from the consumer;
- visibility: what should be public and what details remain inside;
- autonomy: whether the module is complete, valid and delivers results without shared mutable state;
- testability: whether the guarantees can be observed by the API.

When a module is decomposed into others with their own contracts, the same review applies. Don't convert every function, parameter or error into another module.

4. Solve test support

- Keep actual implementations that are practical.
- Reuse existing compatible doubles before creating new ones.
- A shared fake implements a declared subset of the contract and needs its own tests.
- A local stub can prepare a response; a spy or mock observes only messages whose content, quantity or order is contractual.
- Use integration only for authorized risks that depend on real technology.

5. Implement guarantee by guarantee

For each case:

1. select the smallest red test;
2. implement the minimum general rule that satisfies it;
3. run the test and its related group;
4. refactor without changing the API;
5. check that another equivalent implementation could also pass.

If a legacy test is attached inside, first identify what warranty it protected before replacing it.

6. Check and deliver

- Apply format and generation according to the project.
- Run specific tests, reasonable regression scope, relevant lint and static analysis.
- Review the diff to remove temporary support, accidental exports and side changes.
- Report implemented behavior, modified modules and APIs, relevant decisions, commands and results.
- Declare pre-existing failures, risks, out of scope and unexecuted verifications.

Do not declare success if you concealed a deviation by changing the test, if a new guarantee never showed its failure, or if a functional decision remains unresolved.
```

## Expected result

The implementation is complete when all confirmed guarantees are green, the rest of the relevant regression is preserved, and the design still allows changing the interior of each module without breaking its consumers.
