Applied skills retrieval review
An attempt-first review of testing, observability, authentication, ownership, and a TaskFlow change.
Assumes you know
After this you should be able to
- Choose a focused test strategy
- Use logs to narrow a failure
- Plan a safe owner-scoped TaskFlow change
Applied skills · retrieval review
Make the call before seeing the explanation: testing, observability, ownership, authentication, and change design.
Attempt first#
- A service rejects duplicate task titles. What collaborator would you stub, what behavior would you assert, and which interaction is not worth verifying?
- A controller accepts invalid JSON and returns 500. Choose a smallest useful test slice and predict the response contract it should assert.
- A production request is slow but succeeds. Choose two log fields and one level that help correlate the request without turning logs into a data leak.
- A user can read another owner’s task by changing an ID in the URL. Identify the missing check and where it belongs in the request path.
- A bearer token is valid but the endpoint still returns 403. What claims, filter behavior, and authority mapping would you inspect?
- Design a TaskFlow “move task” change that changes owner and project. Which invariants belong in the service, and what should happen if the second update fails?
Completion evidence#
Choose one TaskFlow change above. Write its acceptance checks, implement or sketch its service boundary, and list the test and log evidence you would use to verify it.
Current status: Not started
Open answer structures after your attempt
Start each answer with the observable behavior, then name the narrowest boundary that proves it. Use a mock for isolated service policy and a slice for web binding or validation. Log identifiers and elapsed time, not credentials. Enforce ownership in the service using authenticated identity, and make related state changes one unit of work. Security diagnoses should distinguish token validation from authority conversion.