Module 06 Activity

Scenario

The app is about to do something outside itself. Everything here is about making misuse impossible rather than discouraged.

What you build

Narrow tools with policy validation, idempotency keys, confirmation as a required parameter, and complete call records.

Steps

1. Write one narrow tool with a description aimed at the model and a guarantee in the code. Call it with a hostile input.
2. Validate the arguments in two layers, with at least one policy limit that is not a type check.
3. Give the action an idempotency key from the request id and step name. Prove three calls act once.
4. Sort your actions by effect and gate the irreversible ones with a required confirmed_by parameter.
5. Log attempt, outcome and the external system's id, after the call returns.
6. Confirm no path reaches the gated action without a confirmation.

Evidence to hand in

• The tool with its description and its guarantee.
• The two-layer validator with its policy limit.
• Evidence three calls produce one effect.
• The effect sort and the gated actions.
• One complete call record.
• The path audit for the gated action.

Review checklist

• The guarantee is in code, not in the docstring.
• At least one limit is policy rather than type.
• The key comes from the request and step, not a timestamp.
• Confirmation is a required parameter, not an instruction.
• The log is written after the call returns and includes the attempt number.

Mark complete