Repository navigation
readme: lead with what it is, in plain words - #5
Conversation
The old opening was three quotes and a positioning statement -- accurate, but it explained the product to someone who already knew it. This starts with why a note coming back matters, then the feed, then the promises about privacy, and keeps the architecture below a fold for developers. Also brings it up to date: the notes list is the front door, not the composer; sign-in exists and notes still do not need it; the feed, follows and publishing are built; and both stale claims are corrected -- Expo Go no longer runs this, and the composer rule now says the *note* composer. Status tables say what is actually true, including the two things worth knowing before cloning: no server behind the social layer yet, and no sync between devices. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017DRL4dVgg5oebLSTenQv2G
📝 WalkthroughWalkthroughThe README was substantially rewritten to document DailyNote’s local note flow, optional social sharing, rollout status, account options, privacy guarantees, developer structure, setup commands, and local-only database use before sync. ChangesDailyNote README
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Around line 20-24: Update the four-answer flow description in the README’s
current product-state section to describe the card as upcoming rather than
already available, aligning it with the “next” state referenced later. Preserve
the existing explanation of the four response options.
- Around line 127-131: Update the license entries in the README layout table,
specifically the packages/db and supabase rows, to use the repository’s exact
SPDX license expression consistently with the later AGPL-3.0-or-later reference.
- Line 126: Update the fenced layout block in README.md around line 126 to
specify the text language, changing the opening fence to use text while
preserving the block’s contents and structure.
- Around line 146-165: Clarify the “Getting started” section by distinguishing
Expo Go commands from the native development-build flow required for Google
Sign-In. Label the npm start/android/ios commands as Expo Go mode, and place or
label the prebuild plus platform run commands as native development-build mode
before the credential instructions.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| You get four answers. *Not yet.* *Add update.* *Done.* *Let go.* | ||
|
|
||
| That's the whole idea. Not reminders, not deadlines, not a streak you'll feel bad about breaking. | ||
| Just a note that shows up again at a sensible moment and gives you an easy way to say what | ||
| happened — including "nothing, and I'm letting it go." |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Align the current-state description of the four-answer flow.
Lines 20-24 say users get four answers now. Line 73 says the four-answer card is next. These statements describe different product states. If Line 73 is current, describe the four-answer card as upcoming in the product section.
Also applies to: 73-73
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` around lines 20 - 24, Update the four-answer flow description in
the README’s current product-state section to describe the card as upcoming
rather than already available, aligning it with the “next” state referenced
later. Preserve the existing explanation of the four response options.
|
|
||
| ### Layout | ||
|
|
||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add a language to the layout fence.
markdownlint MD040 flags the fence at Line 126. Use text for this non-code layout block.
Proposed fix
-```
+```text📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ``` |
🧰 Tools
🪛 markdownlint-cli2 (0.23.2)
[warning] 126-126: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 126, Update the fenced layout block in README.md around
line 126 to specify the text language, changing the opening fence to use text
while preserving the block’s contents and structure.
Source: Linters/SAST tools
| apps/mobile Expo app (expo-router, NativeWind) MIT | ||
| packages/core pure TS domain logic, no RN, no Supabase MIT | ||
| packages/db Drizzle schema + Postgres migrations AGPL-3.0 | ||
| supabase migrations, RLS policies AGPL-3.0 | ||
| docs product.md, the two rollout plans, ADRs | ||
| docs product.md, the rollout plans, auth.md, ADRs |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use one exact license expression in the layout table.
Lines 129-130 say AGPL-3.0, while Line 184 says AGPL-3.0-or-later. Use the exact SPDX expression from the repository license metadata in both places.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` around lines 127 - 131, Update the license entries in the README
layout table, specifically the packages/db and supabase rows, to use the
repository’s exact SPDX license expression consistently with the later
AGPL-3.0-or-later reference.
| ### Getting started | ||
|
|
||
| ```bash | ||
| npm install | ||
| npm start # Expo dev server | ||
| npm run android # or: npm run ios | ||
| ``` | ||
|
|
||
| Requires Node ≥ 20.19. The app runs in Expo Go for Phase 1; a development build is needed once | ||
| native modules land in Phase 2. | ||
| Requires Node ≥ 20.19. | ||
|
|
||
| You'll need a **development build** rather than Expo Go — Google Sign-In is native code: | ||
|
|
||
| ```bash | ||
| npx expo prebuild --clean | ||
| npx expo run:android | ||
| ``` | ||
|
|
||
| Sign-in needs credentials. Without them the app still launches, still takes notes and still reads | ||
| the feed; it just can't sign anyone in. Copy `apps/mobile/.env.example` to `.env.local` and see | ||
| [docs/auth.md](docs/auth.md). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔵 Trivial | 💤 Low value
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
while IFS= read -r file; do
printf '\n--- %s ---\n' "$file"
rg -n -C 4 '"(start|android|ios|engines|packageManager)"' "$file" || true
done < <(fd -a -g 'package.json')
rg -n -C 4 '20\.19|node-version|setup-node|NODE_VERSION' \
--glob '*.json' --glob '*.yml' --glob '*.yaml' --glob 'Dockerfile*' .Repository: zacktiger/DailyNote
Length of output: 209
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- package.json files ---'
fd -a 'package.json$' . | while IFS= read -r file; do
printf '\n--- %s ---\n' "$file"
rg -n -C 4 '"(start|android|ios|engines|packageManager)"' "$file" || true
done
echo
echo '--- toolchain references ---'
rg -n -C 4 '20\.19|node-version|setup-node|NODE_VERSION' \
--glob '*.json' --glob '*.yml' --glob '*.yaml' --glob 'Dockerfile*' . || true
echo
echo '--- README start section ---'
sed -n '136,170p' README.mdRepository: zacktiger/DailyNote
Length of output: 19366
🌐 Web query:
Expo managed workflow native modules Google Sign-In need native code prebuild run android documentation
💡 Result:
To implement Google Sign-In in an Expo managed workflow, you must use a development build because these libraries require custom native code and cannot run in Expo Go [1][2][3]. The recommended approach is to use the Expo Prebuild workflow [2][4]. Follow these steps: 1. Choose a Library The official Expo documentation recommends either @react-native-google-signin/google-signin or react-native-nitro-google-signin [1][3]. Note that the legacy Google Sign-In SDK for Android is deprecated, and Google now recommends using Android Credential Manager [3]. The react-native-nitro-google-signin library supports Android Credential Manager, whereas the free/public version of @react-native-google-signin/google-signin uses the legacy SDK (though the latter offers Credential Manager support in a paid/premium version) [3][5]. 2. Install and Configure Install your chosen package using your preferred package manager (e.g., npx expo install @react-native-google-signin/google-signin). 3. Add the Config Plugin You must add the library's config plugin to the plugins array in your app.json or app.config.js file [1][2]. This plugin automatically handles the required native configuration (like Info.plist changes or google-services.json integration) during the prebuild process [2][6]. - If you are using Firebase, provide the path to your google-services.json (Android) and GoogleService-Info.plist (iOS) in your app config [2]. - If you are not using Firebase, you will need to provide the iosUrlScheme as an option to the config plugin [2]. 4. Run Prebuild and Build the App After configuring the plugin, run the following command to generate the native project directories: npx expo prebuild --clean [2] Once prebuild completes, you must create a development build to test the native modules: npx expo run:android npx expo run:ios [2][6] Any subsequent changes to native code or configuration require a full rebuild of the app using these commands [6].
Citations:
- 1: https://docs.expo.dev/guides/google-authentication/
- 2: https://react-native-google-signin.github.io/docs/setting-up/expo
- 3: https://github.com/expo/expo/blob/main/docs/pages/guides/google-authentication.mdx
- 4: https://docs.expo.dev/guides/adopting-prebuild/
- 5: https://github.com/react-native-google-signin/google-signin
- 6: https://www.npmjs.com/package/expo-google-credential-auth
Clarify the two setup modes in the Getting started block.
npm run android / npm run ios starts Expo Go development mode, but Google Sign-In requires the prebuild development build. Move the prebuild/run commands before those scripts, or explicitly label the first group as Expo Go mode and the second group as the native development-build mode.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` around lines 146 - 165, Clarify the “Getting started” section by
distinguishing Expo Go commands from the native development-build flow required
for Google Sign-In. Label the npm start/android/ios commands as Expo Go mode,
and place or label the prebuild plus platform run commands as native
development-build mode before the credential instructions.
1 participant
The old opening was three quotes and a positioning statement -- accurate, but it explained the product to someone who already knew it. This starts with why a note coming back matters, then the feed, then the promises about privacy, and keeps the architecture below a fold for developers.
Also brings it up to date: the notes list is the front door, not the composer; sign-in exists and notes still do not need it; the feed, follows and publishing are built; and both stale claims are corrected -- Expo Go no longer runs this, and the composer rule now says the note composer.
Status tables say what is actually true, including the two things worth knowing before cloning: no server behind the social layer yet, and no sync between devices.
Claude-Session: https://claude.ai/code/session_017DRL4dVgg5oebLSTenQv2G
Summary by CodeRabbit