尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證正在載入完整 README。 以下為已儲存的摘錄。
A household recipe manager: import recipes from any URL, organize them with tags, plan meals for the week, and generate a shopping list from the plan.檢視完整 README ↗A household recipe manager: import recipes from any URL, organize them with tags, plan meals for the week, and generate a shopping list from the plan.
@dnd-kit for drag-and-dropCopy .env.local.example to .env.local and fill in Supabase/Anthropic credentials, then run the dev server:
npm install
npm run dev
Open http://localhost:3000 to see the result.
Database schema and migrations live in supabase/migrations.
npm run dev — start the dev servernpm run build / npm run start — production build/servenpm run lint — ESLintnpm run type-check — TypeScript checknpm run test / npm run test:watch — unit tests (Vitest)npm run test:e2e — end-to-end tests (Playwright)src/app — routes, grouped into (app) (main authenticated app: recipes, planner, shopping, settings, admin), (auth) (login), (flow) (guided flows), and api (route handlers)src/lib — domain logic: ai, scraper, recipes, planner, shopping, tags, auth, supabasesrc/components — UI components by feature areadocs/superpowers — feature specs and implementation plans| Branch | URL | Supabase project |
|---|---|---|
main | https://dapcook.vercel.app | dapcook |
staging | https://dapcook-staging.vercel.app | dapcook-staging |
staging is a permanent, downstream-only integration branch: it carries main
plus whatever is still being tested, and it never merges back into main.
main. It deploys to production, and
.github/workflows/sync-staging.yml merges it into staging automatically.main, merge that branch into staging to test
it on the staging URL, then merge the same branch into main once approved.If staging ever tangles it can be thrown away, because it holds no unique
history:
git checkout staging && git reset --hard origin/main && git push --force origin staging
scripts/apply-migrations.ts applies pending supabase/migrations/*.sql to
staging automatically, tracking what it has run in a schema_migrations table.
Databases that predate that table are recognised by their existing schema and
seeded from supabase/baseline.txt rather than re-migrated. Production
migrations are applied by hand.
See Next.js deployment docs for details.