amal66 makes Mike refuse unsafe deployments

The fork now stops at startup when its essential operating settings are missing, rather than failing later on a sensitive request.

infrastructuresecurity

amal66 is tightening the operational guardrails around Mike's deployment setup. Required service settings are now checked in one place, including the connection to Supabase, a hosted database and authentication service.

That shifts a common failure from the middle of a live workflow to launch time, where it is more visible and easier to correct. The change also strengthens how download access tokens are checked, reducing avoidable risk around protected files. Existing installations should review their settings before updating: deployments that previously started with incomplete configuration may now deliberately refuse to run.

So what Legal teams hosting Mike, and vendors building on it, should care because predictable startup failures are far safer than surprises around client data.

View this fork on GitHub →

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

Commits in this thread

1 commit from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date

9f15ed1c fix(chapter-04): fail fast on config and compare secrets safely Amal 2026-05-24 ↗ GitHub

SHA	Subject	Author	Date
`9f15ed1c`	fix(chapter-04): fail fast on config and compare secrets safely	Amal	2026-05-24	↗ GitHub
commit body Chapter: 04 - Runtime safety basics. Plain-English map: Validate required environment variables at startup, reuse Supabase and storage clients instead of recreating them per request, and remove a timing leak from download-token comparison. Why it matters: Bad configuration should be caught before users hit the app. Shared clients avoid needless connection churn. Secret checks should not reveal clues through response timing. Principle: Fail fast, reuse expensive resources, and compare secrets in constant time. Precedent borrowed: Upstream PRs #81, #106, and #109, which independently targeted timing-safe comparison, env validation, and singleton client reuse. Upstream base: willchen96/mike@d39f580. Original local commit: c2d2a9a.

commit body

Chapter: 04 - Runtime safety basics.

Plain-English map:
Validate required environment variables at startup, reuse Supabase and storage
clients instead of recreating them per request, and remove a timing leak from
download-token comparison.

Why it matters:
Bad configuration should be caught before users hit the app. Shared clients
avoid needless connection churn. Secret checks should not reveal clues through
response timing.

Principle:
Fail fast, reuse expensive resources, and compare secrets in constant time.

Precedent borrowed:
Upstream PRs #81, #106, and #109, which independently targeted timing-safe
comparison, env validation, and singleton client reuse.

Upstream base: willchen96/mike@d39f580.
Original local commit: c2d2a9a.

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-2000.md from inside the repo you want the changes in.

⬇ Download capture-thread-2000.md