docs: correct default admin account password

[makeusabrew]

Description

Update the default admin password in the root-level README.md file to match the current default value from backend/config.env:

EDIT: updated all other references as requested by @bartmichalak

cat backend/config/.env | grep ADMIN
#--- ADMIN SEED ---#
ADMIN_EMAIL=admin@admin.com
ADMIN_PASSWORD=your-secure-password

Checklist

Note: I have left all checklist items unchecked, since this is a one-line docs change.

General

• My code follows the project's code style
• I have performed a self-review of my code
• I have added tests that prove my fix/feature works (if applicable)
• New and existing tests pass locally

Backend Changes

You have to be in backend directory to make it work:

• uv run pre-commit run --all-files passes

Frontend Changes

• pnpm run lint passes
• pnpm run format:check passes
• pnpm run build succeeds

Testing Instructions

Steps to test:

1. Clone the repository
2. Follow the setup instructions in README.md
3. Attempt to login to http://localhost:3000 with the provided credentials

Expected behavior:

Login should now work correctly after following the readme.

Additional Notes

Hi folks! 👋

I hope you don't mind such a simple contribution, but I hit this issue during setup yesterday. Feel free to reject the PR if you'd rather update the default value of the env var to match the docs rather than the other way round.

On a separate note: I love what you're doing here. I've been in the wearables space building fitIQ for the last 3 years and I've evaluated a lot of the commercial wearable aggregators out there during that time. All of them fell short for me, not least the eye-watering cost but also the operational side - when things failed (which they always did), I wasn't just debugging my system and the provider's API, but a third black box in the middle. It's really exciting to me that someone's making a proper go of filling that space transparently and with a permissive license.

fitIQ is currently WHOOP-only, but wearable expansion is always somewhere near the top of the priority list. I'm not sure if I could adopt OpenWearables as things stand today (in no small part due to how tightly coupled my own system is to WHOOP), but I am going to keep a keen eye on things. If that changes, I'd love to contribute properly in the future too.

All the best,

Nick

Summary by CodeRabbit

• Documentation
  • Clarified the default admin password placeholder across the getting-started guide, quickstart, deployment tips, contributing notes, and README — now shown as "your-secure-password" in examples and setup instructions.

[coderabbitai]

📝 Walkthrough

Walkthrough

Updated default admin password examples across documentation and changed the Settings.admin_password default in backend configuration from "secret123" to "your-secure-password". No other behavioral or control-flow changes.

Changes

Cohort / File(s)	Summary
Backend config backend/app/config.py	Changed Settings.admin_password default from SecretStr("secret123") to SecretStr("your-secure-password"). No type or API surface changes.
Documentation README.md, AGENTS.md, contributing/developing.md, docs/deployment/railway.mdx, docs/quickstart.mdx	Updated example admin credential text from secret123 to your-secure-password in multiple docs and guides.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐇 I hopped through docs to tweak a small clue,
From "secret" to "yours" — a password anew.
Code stayed the same, just words in a row,
A tiny update, and now off I go! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 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 describes the main change: correcting the default admin account password in documentation and configuration files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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

[bartmichalak]

Hi @makeusabrew, thanks for raising this - you're right, there is an inconsistency when it comes to admin password.

However, we should change it in a few more places (especially backend/config.py where we set the default value to secret123).
Could you make this change (grep secret123 and replace with your-secure-password (which is actually better than secret123 😅)? Or if you don't mind, I can jump into your branch and make this change.

[bartmichalak]

Also @makeusabrew, I'd love to hear more about the issues you ran into with the SaaS vendors you were using! It could help us shape the roadmap better here. It could help us shaping the roadmap better here

fitIQ is currently WHOOP-only, but wearable expansion is always somewhere near the top of the priority list. I'm not sure if I could adopt OpenWearables as things stand today (in no small part due to how tightly coupled my own system is to WHOOP), but I am going to keep a keen eye on things. If that changes, I'd love to contribute properly in the future too.

Maybe if we enable streaming to your backend via webhooks (it's on the top of the roadmap), it will be easier for you 🙏

[makeusabrew]

Hi @makeusabrew, thanks for raising this - you're right, there is an inconsistency when it comes to admin password.

However, we should change it in a few more places (especially backend/config.py where we set the default value to secret123). Could you make this change (grep secret123 and replace with your-secure-password (which is actually better than secret123 😅)? Or if you don't mind, I can jump into your branch and make this change.

Of course, apologies @bartmichalak - I should have been more thorough. I'll update the other references shortly.

Also @makeusabrew, I'd love to hear more about the issues you ran into with the SaaS vendors you were using! It could help us shape the roadmap better here. It could help us shaping the roadmap better here

I will happily share in detail when I have the time to explain more thoroughly, but in essence it usually boiled down to a combination of bad/outdated docs, opaque/intractable system behaviour (of the SaaS in the middle) and a lack of observability. When things didn't work I would often lose hours debugging my system, then spend time deep diving into the provider's API docs, before being left with no other conclusion to draw that I must have hit a bug in the SaaS provider in the middle. At that point I'd lose more time raising a bug which went unanswered for several days before being confirmed as their issue all along.

Maybe if we enable streaming to your backend via webhooks (it's on the top of the roadmap), it will be easier for you

Sounds very interesting! Anywhere I can read more about this?

[bartmichalak]

Thanks for explaining - yeah, that sounds like a real pain, sorry about the lost hours!

Keeping docs in sync is honestly hard (we're still not great at it ourselves and working on improving), but for products that have been around for years, you'd expect them to have figured that out by now.

the lack of responsiveness - I've heard that from multiple people at this point.

That said, open source seems to resolve those issues - you can just dig into the code yourself (or throw it at an LLM), instead of waiting on support to get back to you.

On the observability front, we've got an open PR adding telemetry:
#425
Should be a solid step forward on that front

Sounds very interesting! Anywhere I can read more about this?

Only this for now:
#99

I've barely started looking into it - it definitely needs more thought and planning, but I'm hoping to have some kind of PoC in the next few weeks.

If you have any lessons learned from previous SaaS experiences that might be relevant for planning - happy to hear about them!

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@backend/app/config.py`:
- Around line 63-64: Current default admin_password (admin_password: SecretStr =
SecretStr("your-secure-password")) leaves a predictable credential in non-local
deployments; change the default so a secure password must be provided and fail
startup when not set in production. Replace the hardcoded SecretStr default for
admin_password with no default (or Optional[SecretStr]=None) and add a
validation in your settings loader / Settings.__post_init__ (or the function
that instantiates Settings) that checks the environment flag (e.g.,
settings.environment or a similar env var) and raises a ValueError if
admin_password is missing/None and environment is not one of the allowed local
values (e.g., "local","development","testing"); ensure the error message clearly
instructs operators to set ADMIN_PASSWORD.

---

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8b343bb and 7f111c4.

📒 Files selected for processing (6)

• AGENTS.md
• README.md
• backend/app/config.py
• contributing/developing.md
• docs/deployment/railway.mdx
• docs/quickstart.mdx

✅ Files skipped from review due to trivial changes (2)

• docs/quickstart.mdx
• AGENTS.md

🚧 Files skipped from review as they are similar to previous changes (1)

• README.md