Assignment: design one controlled save tool
Produce a state diagram for proposed → awaiting approval → executing → completed/rejected/failed. This is a design exercise for a future PocketChat extension; no tool executor exists in the reference app.
Create a decision table for: valid proposal with approval; valid proposal with rejection; unknown tool; oversized text; forged ownership argument; duplicate call after success; interruption between a database write and sending the tool result. Specify what is stored and what is returned to the model for each case.
Use a fake executor or pseudocode test to demonstrate that executing the same approved call twice creates at most one note. Explain how a transaction protects both the execution record and note insertion. A simple in-memory Set of IDs is not enough across process death.
For a read tool, include a consent boundary for sharing local notes with Gemini and a cap on returned text. For both tools, define a maximum round count and a visible terminal state when it is reached.
Submit the diagram, decision table, idempotency evidence, and disclosure wording. Keep any real booking, payment, enrollment, or mentorship scheduling outside scope. Completion demonstrates architectural reasoning, not a claim that the pinned PocketChat app performs model-driven actions.