amal66 makes testing expectations visible

A contributor-facing testing guide and pull-request checklist make verification an explicit part of changing Mike.

workflowinfrastructure

amal66 has documented how contributors should test changes before proposing them, with an emphasis on adding the smallest useful test for a fix or feature. The guidance also asks that optional tests fail safely when their required services are unavailable, so routine checks remain dependable.

A refreshed pull-request template now prompts contributors to explain what changed, the tradeoffs involved, and how they verified it. This does not add new protections by itself, but it makes quality expectations easier to follow and review.

For legal teams assessing whether a fork is being maintained carefully, this is a small but meaningful signal of operational discipline.

So what Maintainers and legal-product buyers should care because repeatable verification reduces the chance that routine changes quietly break a working tool.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`0de61709`	docs(chapter-33): warn contributors how to test safely	Amal	2026-05-24	↗ GitHub
commit body Chapter: 33 - Safe local development. Plain-English map: Document how to avoid using production databases, production buckets, real client documents, or browser-exposed service-role keys during local testing. Why it matters: New contributors can accidentally leak sensitive data or admin credentials while only trying to run the app. The docs should prevent that mistake early. Principle: Good setup docs are a security control. Precedent borrowed: Upstream PR #133. Upstream base: willchen96/mike@d39f580. Original local commit: 5e3608b.
`15b7b4c9`	docs: testing policy in CONTRIBUTING + PR template with verification checklist	QA Runner	2026-07-20	↗ GitHub
commit body Adds a Testing section documenting every suite the testing PR series introduces (unit/integration via vitest, Playwright e2e, offline evals, gated real-Supabase stack tests), the expectation that changes carry tests at the lowest layer that catches the regression, and a PR template (ported from the amal66 fork, Open-Legal-Products/mike#205) whose checklist asks how the change was verified. Intended as the capstone of the series - the commands it documents are introduced by the sibling test PRs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1342.md from inside the repo you want the changes in.

⬇ Download capture-thread-1342.md