docs: rewrite the README to describe the worker that actually exists - #14
Conversation
The code was slimmed to a companion in 2026-06-29 ("slim companion
backend (free-tier)"). The README was not, and still opened with:
"This is the part that does the actual thinking... The app on your
phone is mostly a screen; the work happens here."
None of that is true. There is no /ingest/batch, no decode.ts, no
rollup.ts, no analytics cron, no minute table, no R2 raw archive. The
worker is 749 lines across appconfig / auth / health / reads / telemetry,
and index.ts's own header comment has been accurate the whole time — the
README was the only thing still describing the old architecture.
This matters beyond tidiness. OpenStrap's entire pitch, and a good part of
its legal posture, is that health data is computed and stored on-device
and no server ever sees it. A public repo in the same org claiming to
receive raw frames and compute recovery server-side undercuts that, and
this repo is linked from the org profile.
Rewritten from the actual route table: what each endpoint is for, which
are required (almost none), and that the two data-collecting endpoints
are opt-in, off by default, and compiled out of store builds entirely.
Keeps the self-host instructions and points at migrate_to_slim.sql and
git history for anyone who wants the old design.
|
Warning Review limit reached
Next review available in: 38 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai full review |
✅ Action performedFull review finished. Your included review limit is currently reached under our Fair Usage Limits Policy. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 38 minutes. |
1 participant
Part of a pass over the org's public surface. Sibling PRs: OpenStrap/protocol#17, OpenStrap/analytics#28, OpenStrap/edge#154, OpenStrap/.github#1.
The problem
The code was slimmed to a companion on 2026-06-29 (
feat: slim companion backend (free-tier)). The README was not, and still opened with:None of that exists anymore. There is no
/ingest/batch, nodecode.ts, norollup.ts, no analytics cron, nominutetable, no R2 raw archive. The worker is 749 lines acrossappconfig/auth/health/reads/telemetry, andindex.ts's own header comment has been accurate the whole time — the README was the only thing still describing the old design.Why it matters beyond tidiness
OpenStrap's entire pitch — and a meaningful part of its legal posture — is that health data is computed and stored on-device and no server ever sees it. A public repo in the same org claiming to receive raw frames and compute recovery server-side undercuts that. This repo is linked from the org profile, and its homepage field points at a live worker URL.
What's here
Rewritten from the actual route table: a table of every endpoint, what it's for, and whether it's required (almost none are). States up front and unambiguously that the app doesn't need this worker, and that the two data-collecting endpoints (
/telemetry,/health/upload) are opt-in, off by default, and compiled out of App Store and Play Store builds entirely.Keeps the self-host instructions, and points at
src/db/migrate_to_slim.sqland git history for anyone who wants the old architecture.Worth considering separately
Whether this repo should be archived. It's a genuinely optional companion now, it's the only thing in the org that could be mistaken for a cloud dependency, and archiving would remove that ambiguity permanently. Not doing it in this PR — that's your call, and the README fix stands either way.
Risk
None — documentation only, no code touched.