Capstone: Field Notes team task app

User stories

• As a user, I can sign in and see projects for my team.
• As a project member, I can create a task, edit its details, change its status, and archive it.
• As a connected teammate, I see task changes arrive without manually refreshing.
• As a user, I never see or change data belonging to another team.
• As a user on a mobile network, I get a clear result when a request times out or connectivity drops.

Suggested API surface

TaskService: CreateTask, GetTask, ListTasks, UpdateTask, DeleteTask, and server-streaming WatchTasks. Add ProjectService for listing/creating projects and SessionService only if time permits. Scope every request by project/team identity derived from the authenticated principal; never trust a client-supplied owner ID as authorization.

Use google.protobuf.Timestamp for timestamps, stable numeric field tags, explicit page size and opaque page token fields, and an enum with an UNSPECIFIED = 0 value. Prefer an update mask or explicit patch semantics so omitted fields are not confused with default values.

Vertical slices

1. Health/readiness and one unary GetTask call.
2. Create and list tasks, then render loading/empty/error/success states in Flutter.
3. Update status and persist through a repository backed by PostgreSQL.
4. Authenticate and enforce team scoping on every operation.
5. Watch updates; reconnect with bounded backoff and refresh a snapshot after reconnect.
6. Package, document, and demo the complete flow.

Acceptance checklist

• A clean checkout has documented generation, migration, run, and Flutter launch commands.
• Go and Dart stubs are regenerated from the checked-in .proto contract.
• CRUD operations validate fields and map failures to appropriate gRPC status codes.
• List calls are bounded and paginated.
• Stream cancellation stops server work; clients recover by reconnecting and reloading state.
• Authentication and team-level authorization are enforced server-side.
• TLS is used for deployed traffic; secrets are configured outside source control.
• Database migrations are repeatable and persistence survives service restart.
• Tests cover domain logic, handlers, authorization, and at least one end-to-end client call.
• Logs include request context/correlation without tokens or sensitive task content.

Demo script

Run the service and Flutter app; sign in as two team members on separate clients; create a task in one and show it appear in the other; mark it done; stop/restart the service and confirm data persists; then show that a user from another team cannot fetch it.