I build iOS apps
at Microsoft.

Illustrative brief for a common mobile interaction, not a verbatim company prompt or a claim that every listed test exists in a shipped feature.

Scenario: A poll vote should appear immediately, even on a slow connection. A failed request must not leave an incorrect vote on screen.

Read first: Trace the existing view model, persistence and network action. Identify which layer owns the vote state and find the established error-handling pattern.

Before coding: Explain the current behavior, identify assumptions and propose the smallest change. Do not invent APIs or assume a successful network response.

Constraints: Reuse existing storage and concurrency rules. Preserve multi-select behavior and accessibility. Keep unrelated refactors out of scope.

Acceptance criteria: Test success, failure and rollback, repeated taps, multi-select changes, and leaving the screen during a request. Check out-of-order responses rather than assuming they arrive in sequence.

Handoff: Run the relevant checks and report their actual output. Distinguish verified behavior from anything not tested. Do not deploy without approval.

Illustrative public-safe rules. My private instruction files and company-specific guidance are not published here.

# Working rules

- Read the repository guidance and relevant implementation before proposing code.

- Check APIs against the project's SDK and documentation. State uncertainty instead of filling a gap with a plausible name.

- Turn assumptions into questions or tests. Do not change requirements silently.

- Preserve existing behavior outside the task and follow the established architecture.

- Test failure paths and accessibility, not only the successful interaction.

- Report actual command output. A proposed test is not a passing test.

- Keep private code, customer data and internal metrics out of public artifacts.

- Ask for approval before publishing. Keep the human responsible for the final decision.