尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證kotdok
翻譯準備中
取自儲存庫 README
正在載入完整 README。
檢視完整 README ↗This is a Next.js project bootstrapped with create-next-app.
The app supports requesting one extra symptom check when user credits are exhausted. Admin confirmation is done from a Telegram channel message with inline buttons.
Add these variables to .env.local:
TELEGRAM_BOT_TOKEN=123456:your-bot-token
TELEGRAM_APPROVAL_CHAT_ID=-1001234567890
TELEGRAM_WEBHOOK_SECRET=your-random-secret
Webhook endpoint in this app. Use the Vercel domain, not lapka.my: Telegram's
servers cannot connect to the Russia proxy in Yandex Cloud (Connection timed out), so the approve button never reached the app through it
(docs/architecture/ru-proxy.md, «Мимо прокси»).
https://kotdok.vercel.app/api/telegram/webhook
Production's TELEGRAM_* values are Sensitive in Vercel and cannot be read
back; to re-point the webhook there, set a new secret first (same doc section).
Set Telegram webhook:
curl -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/setWebhook" \
-H "Content-Type: application/json" \
-d '{
"url": "https://kotdok.vercel.app/api/telegram/webhook",
"secret_token": "'"${TELEGRAM_WEBHOOK_SECRET}"'"
}'
Quick health check:
credits = 0).profiles.credits increases by +1 and a credit_ledger row with reason = admin_grant appears.First, run the development server:
npm run dev --workspace @lapka/web
Open http://localhost:3000 with your browser to see the result.
You can start editing the page by modifying apps/web/src/app. The page auto-updates as you edit the file.
This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.
apps/web/ Next.js site and API
apps/mobile/ Expo client (placeholder screen until stage 4)
packages/contracts/ API contracts shared by both apps (skeleton until stage 1)
packages/shared/ portable helpers and dictionaries (skeleton until stage 1)
supabase/ migrations and local stack config
docs/ roadmap, verification reports, architecture notes
npm workspaces, one lockfile at the repository root. npm ci from a clean
checkout installs every workspace.
Each application is checked on its own; the web build needs neither Xcode, the Android SDK, nor a running Metro.
npm run lint --workspace @lapka/web
npm run typecheck --workspaces --if-present
npm run test --workspace @lapka/web
npm run test:integration --workspace @lapka/web
npm run build --workspace @lapka/web
npm run typecheck --workspace @lapka/mobile
npm run export:ios --workspace @lapka/mobile
npm run export:android --workspace @lapka/mobile
The export commands produce JavaScript bundles and assets, not signed apps. Signed development builds are stage 4 of the roadmap.
The Expo app calls http://localhost:3000 and signs in against the staging
Supabase project, so its product screens only work when a site backed by the
same project is listening there. Plain npm run dev is not that site: it
reads .env.local, which holds production credentials, and the phone's token
would be rejected by an API backed by a different project.
Use the staging server instead:
npm run dev:staging --workspace @lapka/web
It reads apps/web/.env.staging (public values, committed) together with
apps/web/.env.staging.local, which is not committed and holds one line:
SUPABASE_SERVICE_ROLE_KEY=<service role key of the staging project>
Take that key from the staging project in the Supabase dashboard, under Project Settings → API Keys. The script refuses to start if the key belongs to another project or is not a service role key — pointing a development server at production with that key in hand is the mistake worth preventing.
CI routes changes to the group that needs them: web changes run the web checks,
mobile changes the mobile ones, and shared packages, the root lockfile or build
settings run both. The rules live in .github/scripts/changed-groups.mjs and
are covered by npm run test:ci-routing.
React 19.2.4 is shared by Next.js and React Native. React Native is pinned to
0.86.3, the version Expo SDK 57 bundles; @expo/cli declares it as an optional
peer with range *, so the root overrides entry keeps npm from hoisting a
newer copy beside it.
Integration tests run against a throwaway local Supabase stack, never against a hosted project. Docker and the Supabase CLI are required.
supabase start # Postgres on 127.0.0.1:54322, API on 127.0.0.1:54321
supabase db reset # applies every migration to an empty database
npm run test:integration --workspace @lapka/web
supabase/migrations/20260101000000_init_baseline.sql recreates the original
schema, so a clean database can be built from the repository alone. Migration
filenames must keep a unique 14-digit version prefix — the CLI rejects the set
otherwise.
npm run test:integration --workspace @lapka/web reads apps/web/.env.integration, which holds only the fixed
public keys the Supabase CLI ships for every local stack. The guard in
apps/web/tests/support/db-guard.ts refuses any destructive operation whose target is
not 127.0.0.1:54322 / 127.0.0.1:54321, so the suite cannot reset a hosted
database even if those URLs are edited by mistake.
Fixtures (apps/web/tests/integration/fixtures.ts) seed two unrelated owners with their
own pets, symptom checks, balances, credit ledger movements and one billing
transaction; reseeding produces the same data set.
To learn more about Next.js, take a look at the following resources:
You can check out the Next.js GitHub repository - your feedback and contributions are welcome!
The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.
Check out our Next.js deployment documentation for more details.