chore(governance): PR template with Red-then-green DoD (G-1)

[SharedQA]

Adds .github/PULL_REQUEST_TEMPLATE.md — the author-facing Definition of Done from the stabilization plan (task G-1).

Red-then-green is the headline rule: a fix lands with a test that failed before it and passes after, with the expected value derived from the spec (not current output).

The Data and UI checklists are pulled straight from the bug classes that recurred: connector→silver reach (#1319/#1334), gold-view resolution (#1330), enforced dbt contracts / type drift (#1318/#1323), golden-value parity (#1324), non-nullable dedup keys (#1330/#1348), honest NULLs + render-contract error-vs-empty (#1336/#1337).

Moves QA from chasing people to GitHub asking the author to declare it — the next step is CI mechanically confirming each promise.

Summary by CodeRabbit

• Chores
  • Added a complete pull request template to standardize submissions, including required “What & why” sections, a Definition of Done checklist, and an Evidence area for pasting verification, coverage deltas, and test outcomes.

[coderabbitai]

Warning

Review limit reached

@SharedQA, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 56 minutes and 32 seconds. Learn how PR review limits work.

To continue reviewing without waiting, enable usage-based billing in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 89eca131-9b94-4e1b-8794-25a92c5b5f42

📥 Commits

Reviewing files that changed from the base of the PR and between 9e10fee and e841784.

📒 Files selected for processing (1)

• .github/PULL_REQUEST_TEMPLATE.md

📝 Walkthrough

Walkthrough

A new .github/PULL_REQUEST_TEMPLATE.md file is added with 40 lines defining structured PR sections: "What & why", a "Definition of Done" checklist covering gating, coverage, testing, and negative-path items, plus a prefilled Evidence area for test summaries and gate output.

Changes

Pull Request Template

Layer / File(s)	Summary
PR template sections and checklist .github/PULL_REQUEST_TEMPLATE.md	Adds the complete PR template with "What & why", Definition of Done checklist (gating, coverage, testing, negative-path), and a prefilled Evidence section for test/coverage/gate outputs.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

A bunny hops in with a checklist in paw,
"No PR shall pass without filling each draw!"
✅ Tests? ✅ Coverage? ✅ Negative path too?
The template is planted, the structure brand new.
Now every merge request knows just what to do! 🐇

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically summarizes the main change: adding a PR template that implements a 'Red-then-green' Definition of Done for governance.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (2)

.github/PULL_REQUEST_TEMPLATE.md (2)

15-15: 💤 Low value

Define "the ratchet" jargon.

Line 15 uses the term "the ratchet" without explanation. While context suggests it refers to coverage ratcheting (fail if coverage falls below the base branch), this terminology is not explicitly defined. New contributors may not recognize the term.

Consider adding a brief clarification, e.g., Coverage held or raised vs the base branch (**ratchet**: fail if coverage drops).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/PULL_REQUEST_TEMPLATE.md at line 15, The checkbox item on line 15 of
the PULL_REQUEST_TEMPLATE.md uses the term "the ratchet" without explanation,
which may confuse new contributors unfamiliar with the terminology. Add a brief
clarification immediately after or adjacent to "the ratchet" to explain that it
refers to the coverage ratcheting mechanism that fails if coverage drops below
the base branch level. For example, you can add inline parenthetical text like
"(ratchet: fail if coverage drops)" or similar wording to make the term explicit
and self-documenting.

---

14-14: 💤 Low value

Clarify what make check includes.

Line 14 invokes make check as a gating criterion but does not define which checks/gates are included (fmt, lint, typecheck, tests, etc.). New contributors may not know what this target does or whether it exists in their environment.

Consider either:

1. Documenting make check in the repository root (Makefile, README, or CONTRIBUTING guide), or
2. Expanding the comment inline to enumerate the gates (e.g., make check (lint · type · test · gates) with a link to the actual target).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/PULL_REQUEST_TEMPLATE.md at line 14, The pull request template at
line 14 references `make check` without explaining what checks it includes,
which may confuse new contributors. Update the inline comment on that line to
explicitly enumerate the checks that `make check` performs (such as fmt, lint,
typecheck, tests, and relevant gates), making it clear what verification steps
are required before pushing. Additionally, consider adding documentation for the
`make check` target in the Makefile, README, or CONTRIBUTING guide to provide
full context about what this command does and ensure contributors can easily
understand and run it in their environment.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/PULL_REQUEST_TEMPLATE.md:
- Line 15: The checkbox item on line 15 of the PULL_REQUEST_TEMPLATE.md uses the
term "the ratchet" without explanation, which may confuse new contributors
unfamiliar with the terminology. Add a brief clarification immediately after or
adjacent to "the ratchet" to explain that it refers to the coverage ratcheting
mechanism that fails if coverage drops below the base branch level. For example,
you can add inline parenthetical text like "(ratchet: fail if coverage drops)"
or similar wording to make the term explicit and self-documenting.
- Line 14: The pull request template at line 14 references `make check` without
explaining what checks it includes, which may confuse new contributors. Update
the inline comment on that line to explicitly enumerate the checks that `make
check` performs (such as fmt, lint, typecheck, tests, and relevant gates),
making it clear what verification steps are required before pushing.
Additionally, consider adding documentation for the `make check` target in the
Makefile, README, or CONTRIBUTING guide to provide full context about what this
command does and ensure contributors can easily understand and run it in their
environment.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0b95fc7e-ce34-47df-a3e0-885c250d8697

📥 Commits

Reviewing files that changed from the base of the PR and between 93ce70e and dec7f1a.

📒 Files selected for processing (1)

• .github/PULL_REQUEST_TEMPLATE.md

[cyberantonz]

Some questions