Engineering workflow guard

Use this guard before changing an existing mobile app. The goal is not a cosmetically clean Git status; it is a codebase where every change has an owner, purpose, test result, and recoverable source location.

Non-negotiable invariants

• Preserve existing work. Never use reset, checkout, clean, stash-drop, branch deletion, force-push, or broad file replacement to make a repository look clean without explicit owner approval and an exact target.
• Follow explicit user and repository rules for checkout, branch, commit, and integration strategy. A project may require direct work on its primary branch; do not invent a conflicting branch or worktree requirement. If permitted and useful, isolate concurrent writers in task worktrees. Otherwise assign disjoint files in the approved checkout and serialize shared-file changes. The word “worktree” in an agency organization does not authorize creating a Git worktree.
• One task has one dominant outcome, one owner, one approved source location, and one completion receipt. Split unrelated changes instead of bundling them into a convenient large commit.
• A commit is a saved checkpoint, not proof that a feature reached main; a merge is not proof that it is backed up remotely; a successful build is not proof that the installed simulator uses the intended source.
• Never expose credentials, signing material, private user data, or production secrets in source, prompts, logs, fixtures, screenshots, generated artifacts, or commit messages.

Start with a read-only baseline

Before editing, inspect and report: