Update production launch checklist with build failure note and re-ver…

[BigJohn-dev]

Closes #381

Pull Request Documentation

Purpose: centralize pull-request guidance, checklist, and best practices for contributors and maintainers.

Use this document to prepare PRs, ensure consistent review standards, and speed up merging.

1. When to open a PR

• Feature work: open a PR from a short-lived feature/* branch targeting main or the active development branch.
• Bugfix: open from fix/* or hotfix/*.
• Docs / Chore: docs/* or chore/*.

2. Required PR contents

• Title: Conventional prefix (e.g., feat:, fix:, docs:, chore:) followed by a short description.
• Summary: one-paragraph description of the change and motivation.
• Type of change: feature, fix, docs, refactor, tests, CI, chore.
• Testing instructions: how a reviewer can run tests locally (commands) and what to verify.
• Linked issues: Closes #NNN or related issue links.
• CI / Build results: include CI run status; ensure CI is green before merging.

3. Local pre-submit checklist (authors must complete before creating PR)

• Branch rebased onto main (or the target branch).
• cargo build --workspace completes with no errors.
• cargo test --workspace passes (or targeted tests pass for large suites).
• cargo clippy --all-targets --all-features and fix critical lints where applicable.
• No unwrap() / expect() in new production code.
• Documentation updated when public APIs change.
• CHANGELOG or release notes entry included if applicable.

4. Reviewer checklist (maintainers)

• Build & CI: verify CI is green and the build succeeds locally for significant changes.
• Correctness: confirm logic, edge cases, and error handling match expected behavior.
• Security: check access control, input validation, and any external calls.
• Tests: ensure sufficient unit/integration coverage; request more tests if gaps exist.
• Size & Performance: watch for large WASM size increases and expensive runtime ops.
• Docs & UX: validate README or user-facing docs updates for new features.

5. How to run common checks locally

Build workspace:

cd dongle-smartcontract
cargo build --workspace

Run all tests (may be slow):

cd dongle-smartcontract
cargo test --workspace

Run a focused test:

cd dongle-smartcontract
cargo test <test_name>

Run WASM release build for deployment validation:

cd dongle-smartcontract
cargo build --target wasm32-unknown-unknown --release

6. CI expectations and merge policy

• All PRs must have passing CI pipelines before merging unless explicitly approved by a release manager for emergency fixes.
• If CI is flaky, annotate the PR and contact infra team; do not merge while the majority of required jobs are failing.

7. PR Template and examples

• A recommended PR description template lives in .github/pull_request_template.md (used by GitHub UI or copy/paste).
• Existing example PRs: see CREATE_PR_INSTRUCTIONS.md and SLUG_PR_SUMMARY.md for demonstration of a well-written PR.

8. Post-merge actions

• Rebase and fast-forward strategy: prefer merging via GitHub UI with a merge commit or squash commits when appropriate.
• After merge: update deployments.json and tag the commit for any release deployments that include contract changes.

9. Troubleshooting

• PR not showing on GitHub: ensure branch pushed to origin and target branch exists.
• Failing tests locally but passing CI: check toolchain differences and feature flags.

10. Contact points

• For release/merge approvals contact the repo owners listed in README.md or the OWNERS file if present.

---

This document is a living reference. If you want additions or stricter checks (e.g., mandatory WASM size gate), open a PR against this file.

Pull Request Documentation

Purpose: centralize pull-request guidance, checklist, and best practices for contributors and maintainers.

Use this document to prepare PRs, ensure consistent review standards, and speed up merging.

1. When to open a PR

• Feature work: open a PR from a short-lived feature/* branch targeting main or the active development branch.
• Bugfix: open from fix/* or hotfix/*.
• Docs / Chore: docs/* or chore/*.

2. Required PR contents

• Title: Conventional prefix (e.g., feat:, fix:, docs:, chore:) followed by a short description.
• Summary: one-paragraph description of the change and motivation.
• Type of change: feature, fix, docs, refactor, tests, CI, chore.
• Testing instructions: how a reviewer can run tests locally (commands) and what to verify.
• Linked issues: Closes #NNN or related issue links.
• CI / Build results: include CI run status; ensure CI is green before merging.

3. Local pre-submit checklist (authors must complete before creating PR)

• Branch rebased onto main (or the target branch).
• cargo build --workspace completes with no errors.
• cargo test --workspace passes (or targeted tests pass for large suites).
• cargo clippy --all-targets --all-features and fix critical lints where applicable.
• No unwrap() / expect() in new production code.
• Documentation updated when public APIs change.
• CHANGELOG or release notes entry included if applicable.

4. Reviewer checklist (maintainers)

• Build & CI: verify CI is green and the build succeeds locally for significant changes.
• Correctness: confirm logic, edge cases, and error handling match expected behavior.
• Security: check access control, input validation, and any external calls.
• Tests: ensure sufficient unit/integration coverage; request more tests if gaps exist.
• Size & Performance: watch for large WASM size increases and expensive runtime ops.
• Docs & UX: validate README or user-facing docs updates for new features.

5. How to run common checks locally

Build workspace:

cd dongle-smartcontract
cargo build --workspace

Run all tests (may be slow):

cd dongle-smartcontract
cargo test --workspace

Run a focused test:

cd dongle-smartcontract
cargo test <test_name>

Run WASM release build for deployment validation:

cd dongle-smartcontract
cargo build --target wasm32-unknown-unknown --release

6. CI expectations and merge policy

• All PRs must have passing CI pipelines before merging unless explicitly approved by a release manager for emergency fixes.
• If CI is flaky, annotate the PR and contact infra team; do not merge while the majority of required jobs are failing.

7. PR Template and examples

• A recommended PR description template lives in .github/pull_request_template.md (used by GitHub UI or copy/paste).
• Existing example PRs: see CREATE_PR_INSTRUCTIONS.md and SLUG_PR_SUMMARY.md for demonstration of a well-written PR.

8. Post-merge actions

• Rebase and fast-forward strategy: prefer merging via GitHub UI with a merge commit or squash commits when appropriate.
• After merge: update deployments.json and tag the commit for any release deployments that include contract changes.

9. Troubleshooting

• PR not showing on GitHub: ensure branch pushed to origin and target branch exists.
• Failing tests locally but passing CI: check toolchain differences and feature flags.

10. Contact points

• For release/merge approvals contact the repo owners listed in README.md or the OWNERS file if present.

---

This document is a living reference. If you want additions or stricter checks (e.g., mandatory WASM size gate), open a PR against this file.