garrytan/gstack

Start with the customer problem, not a solution. State the target user, their context, the current alternative, why the problem matters now, and the desired outcome. Separate facts from assumptions; do not proceed until the problem statement and success hypothesis can be tested.

Decide whether this deserves investment now. Challenge the expected impact, strategic fit, differentiation, opportunity cost, and downside; explicitly identify what will not be built. Choose proceed, stop, or learn more. Proceed only when the scope, non-goals, and decision owner are clear.

Translate the approved scope into an implementation approach. Examine the architecture, data model, interfaces, dependencies, migrations, failure modes, security implications, and test strategy. Record material trade-offs and risks. Do not begin the build with an unresolved technical blocker.

Review the change independently from its implementation. Check correctness, security, maintainability, test coverage, operational impact, and alignment with the approved scope. Classify findings by severity, return blockers with actionable fixes, and verify that every blocker is resolved.

Validate the real user journey in the browser or relevant client. Exercise the primary path, important permissions and error states, and the edge cases identified in planning. Capture reproducible evidence for failures. Pass QA only when the intended experience works without a release-blocking defect.

Confirm the latest tests, review, and QA evidence before preparing the release. Summarize user-facing changes, deployment steps, rollback considerations, and ownership after launch. Do not ship with an unresolved blocker or an unknown deployment prerequisite.