Repository Workflow Is a Form of Risk Control

Start with source truth

Before implementation, inspect the current branch, working tree, relevant instructions, and the files nearest to the requested behavior. This is not a ritual. It reveals whether another person has active edits, whether a route or component already has a local pattern, and whether a change belongs in a different layer than first assumed.

Source truth also limits overclaiming. A green type check can establish that code compiles; it cannot establish that a feature is deployed, that external data is current, or that an integration has authority to act. Keeping those evidence levels separate makes a handoff more credible.

• Confirm the exact file boundary before editing.
• Read the existing contract and nearby tests before changing behavior.
• Treat generated output and production state as separate evidence.

Make changes reviewable

Small, coherent changes are easier to reason about than broad rewrites. A reviewer can compare the new behavior with the stated intent, inspect error paths, and see whether validation covers the risk introduced. This does not mean every change must be tiny; it means the scope should be explicit enough that reviewers can identify what is intentionally out of bounds.

A useful review packet includes the problem being solved, exact changed paths, named checks, and remaining uncertainty. It does not need a transcript of every command. The point is to preserve decision context so the next person can understand why the change exists.

• Keep unrelated formatting and metadata churn out of a focused change.
• Name assumptions that could alter the implementation or release decision.
• Use independent review when behavior or public contracts change materially.

Validation has a boundary too

Different checks answer different questions. Type checking finds type-level inconsistencies. Unit tests exercise selected behavior. Browser checks reveal layout and interaction issues. A deployment smoke check may establish that a specific deployed route responds. None should be reported as broader proof than it provides.

This vocabulary protects teams from accidental escalation. A source-only task can deliver a source-only result with a clear next validation step, rather than implying that an unapproved deploy or external integration has occurred.