我会采用 harness 模式开发，也就是先搭建好工程脚手架、配置好开发环境、准备好需求文档和 API 文档，然后让 Codex 在 Harness 的约束下，使用 /goal 模式一次性完成开发。

项目介绍：

复刻一个Lovart：给你的产品添加上画布模式。

项目开发：

使用 /goal 的核心原则：

/goal 不是魔法，它的效果完全取决于你提供的上下文质量。AI 需要足够的信息才能做出正确决策：

• 需求文档（PRD): 明确产品功能、交互细节、边界条件
• API 文档：第三方服务的接口说明、参数格式、调用示例
• 技术约定（AGENTS.md): 项目的技术栈、目录结构、代码风格
• 参考截图： UI 设计稿、交互流程图

为什么要用 /goal?

我目标是“开发一个完整的画布生图应用”。这个任务包含：

• 前端页面开发（3 个主要页面）
• 数据库表设计和 RLS 策略
• 图片上传和存储
• 第三方生图 API 集成
• 状态管理和实时更新

1.在codex中去用next.js的模板直接可以输入提示词即可拉取，非常方便，我认为codex真的很强不止这一方面。

帮我再这个文件夹下初始化这个next.js项目模板：https://vercel.com/templates/next.js/supabase

2.创建数据库
在supabse中获取环境变量，密钥
在codex中安装supabase mcp，并且连接项目

supabase mcp 大幅度减少了我们操作supabase的流程，不需要去supabase的控制台。

3.创建AGENTS.md

请帮我在当前项目根目录初始 `AGENTS.md` 文件，用中文。

要求：

1. 项目背景
   - 说明这是一个基于 Next.js + Supabase 的项目。
   - 后续开发需要优先遵循当前项目已有的技术栈、目录结构和代码风格。

2. 项目文档目录约定
   - 相关项目文档统一放在 `/docs/` 目录下。
   - `/docs/prd.md`：存放项目需求文档、功能规格、已确认的产品决策。
   - `/docs/images/`：存放截图、界面参考图、流程图等图片资料。
   - `/docs/api/`：存放 API 文档、接口约定、第三方服务对接说明。

3. 需求沉淀规则
   - 当我和你讨论功能实现、产品需求、业务规则或交互细节时，如果某些需求已经明确，请及时整理并写入 `/docs/prd.md` 的文档
   - 写入 PRD 前，需要基于已经确认的信息，不要把未经确认的猜测当成最终需求。
   - 如果需求还不完整，可以先记录为“待确认问题”或“开放问题”。

4. Supabase 操作规则
   - 执行和 Supabase 相关的任务时，尽可能优先使用 Supabase MCP 完成操作，包括但不限于：
     - 数据库表结构查看
     - SQL 查询
     - RLS 策略检查和创建
     - Storage Bucket 的查看和创建

5. 安全和配置约定
   - 不要把 Supabase service role key、数据库密码、访问令牌等敏感信息写入前端代码或提交到仓库。
   - 前端只能使用 `NEXT_PUBLIC_` 开头的公开环境变量。
   - 涉及用户数据访问时，需要优先考虑 RLS 策略和最小权限原则。

6. 编辑方式
   - 如果 `AGENTS.md` 已存在，请在保留原有有效内容的基础上合并更新，不要无意义覆盖。
   - 如果 `/docs/`、`/docs/prd.md`、`/docs/images/`、`/docs/api/` 不存在，可以一并创建。

4./protected 页面 /projects 页面 /canvas 页面

分别描述每个页面的功能，并且把相应的流程整理进入prd.md产品需求文档
把相关生图的API文档写入docs文件下

5.开发前的检查

交给codex进行检查

OK，我现在想做的产品需求我相信你已经明确了。我是希望做一个基于画布模式的生图产品。请你检查一下我的需求文档，看看需求上有哪些不明确的地方，或者技术上有什么需要补充的文档，以及缺失的环境变量。

当前的需求文档中说，如果有你认为能直接决定的部分，你就不用再问我了，一定要是由我来定夺，或者缺失的地方你再要问我。

6.根据需求文档开发前后端

项目缺点：

阉割了很多的功能需要去进一步完善。

此项目仅仅是为了测试harness engineer开发，使项目开发更稳定。