PT-2714: Add Design Principles and UX Review Process Storybook articles

[merchako]

Summary

• Adds Guidelines/UI Review — a checklist-led article (written by Alex Mercado, UX) covering how to get a UI work item through UX review to Done:
  • Pre-review checklist for quick reference
  • Submission instructions with Discord channel links
  • Reference section: Jira UX review property states, acceptance criteria ownership table (code review, UX review, QA), subtask review model, Storybook deliverable requirement, and how to link to reference UI
• Adds Guidelines/Design Principles — styling defaults, semantic color pairing, editor toolbar conventions, keyboard shortcut formatting, and keyboard navigation/focus guidance

Jira

https://paratextstudio.atlassian.net/browse/PT-2714

🤖 Generated with Claude Code

---

This change is 

[irahopkinson]

Thanks for getting this started.

@irahopkinson reviewed 3 files and all commit messages, and made 7 comments.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on merchako).

---

lib/platform-bible-react/src/stories/guidelines/design-principles.mdx line 0 at r1 (raw file):
What about tooltips in general? Where should they be typically used? What about in toolbars?

---

lib/platform-bible-react/src/stories/guidelines/design-principles.mdx line 54 at r1 (raw file):

---

## Editor toolbars and action buttons

What about button verbage? Should it be OK and 'Cancelor should the OK text be a call to action? Is action text likeSaveenough or should it beSave comment`?

---

lib/platform-bible-react/src/stories/guidelines/ui-review.mdx line 18 at r1 (raw file):

### Pre-Review Checklist
- [ ] Acceptance criteria are checked off or explicitly declared in the Jira work item

We have been using Definition of done rather than Acceptance criteria. It would be better if this doc used the right term.

Code quote:

Acceptance criteria

---

lib/platform-bible-react/src/stories/guidelines/ui-review.mdx line 22 at r1 (raw file):

- [ ] Storybook stories or documentation demonstrate the work
- [ ] The PR description links to any reference UIs using specific file paths and [Storybook](https://paranext.github.io/paranext-core/platform-bible-react-storybook/) links
- [ ] (optional) A narrated before/after video or screen recording is posted in the PR description or Jira work item, or else a meeting is requested

BTW this hasn't been optional - lately we have asked devs to add video to all their PRs where appropriate.

---

lib/platform-bible-react/src/stories/guidelines/ui-review.mdx line 32 at r1 (raw file):

- A brief description of what was done

Also include a link to the Jira work item **in the PR description**, so it is traceable from the code change.

BTW we don't typically do this because we don't want the GH repo commits littered with Jira links. However typically a branch name starts with the Jira code and at least one commit starts with the Jira code (which serves as a "link"). Is this sufficient? If we put the Jira link in the UX Discord thread why does it need to be in the PR description also?

---

lib/platform-bible-react/src/stories/guidelines/ui-review.mdx line 49 at r1 (raw file):

| `review not needed` | UX approval explicitly not required |

### Acceptance criteria

We have been using Definition of done rather than Acceptance criteria. It would be better if this doc used the right term.