The project
Expose task search and confirmed task creation through AppFunctions and verify discovery and execution on supported Android.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What AppFunctions exposes
Understand app capabilities as agent-accessible operations. Apply the module decision to this project. Your checkpoint: You can explain both the capability and the current rollout limitations.
2. Project configuration and registration
Connect generated metadata with the app’s service entry point. Apply the module decision to this project. Your checkpoint: The function appears in device-level discovery with the intended schema.
3. Designing typed capabilities
Make the public function contract understandable and stable. Apply the module decision to this project. Your checkpoint: A caller can understand the contract without knowing your internal repository classes.
4. Permissions, identity and confirmation
Treat discovered functions as another external entry point. Apply the module decision to this project. Your checkpoint: External invocation cannot bypass the checks used by the normal app UI.
5. Discovery and execution testing
Use development tools to verify the complete function lifecycle. Apply the module decision to this project. Your checkpoint: You can isolate platform availability from function correctness.
6. Agent-ready product delivery
Ship an integration whose limits are visible and recoverable. Apply the module decision to this project. Your checkpoint: Your demo distinguishes working local integration from restricted production assistant availability.
Acceptance criteria
- Verify registration and invocation using the supported development tools
- Enforce record ownership and confirmation inside the app
- Document preview limitations and behavior on unsupported devices
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.