尚未检测到更新。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.