Jyoti/tradepilot-ai-wave2
1
0
Fork 0
forked from opc-2026-shuzhi-w2-july/track-51
Code Issues 5 Pull requests Activity

【S1W2 交叉评测】对项目 tradepilot-ai-wave2 的反馈 #2

New issue
Open
opened 2026-05-15 21:23:19 +08:00 by yishan · 1 comment
yishan commented 2026-05-15 21:23:19 +08:00
Copy link

1. 项目理解

我理解这个项目主要想解决：

TradePilot AI（拿货搭子）是一个面向小商品进货决策与爆款测款的 AI 智能体，核心解决三个痛点：

  • 进货盲目：新手卖家凭感觉拿货，缺少利润测算、风险判断、品类匹配等理性决策环节。
  • 测款无方向：拿货后不知道怎么在内容平台（小红书/抖音）测款，缺少文案、场景、标题等实操指导。
  • 缺乏复盘：一次进货判断做完就结束，没有将数据沉淀为可比较的产品库、PK 对比和测款复盘闭环。

项目围绕「产品信息采集 → 图片识别 → 利润测算 → 风险判断 → 内容测款建议 → 产品库沉淀 → 候选产品 PK → 测款复盘」构建了完整的业务工作流。技术侧使用 React + Vite + Tailwind CSS 构建前端，通过 Vercel Serverless Function 调用阿里云百炼视觉模型做图片识别，游客模式下用 localStorage 做产品数据持久化，预留学生用 Supabase 做用户鉴权和云端存储。

2. 项目优点

  • 领域知识深厚：项目对「小商品进货」场景有深度理解，内置了饰品、发饰、家居生活、文创纸品、数码周边、低价日用 6 大品类模板，每个品类都有独立的评分逻辑、风险提示、内容文案结构、抖音脚本分镜，甚至是供应商沟通问题清单。这在同类参赛项目中非常少见。

  • 品类识别引擎自成体系：App.jsx 中的 productIdentityProfiles 是一个亮点，不是简单做品类关键词匹配，而是为每个细分品类定义了 strongTerms / weakTerms / allowedTerms / bannedTerms 四层词库，结合加权评分来做产品身份推断。比如能区分「挂在包上的木珠挂件」和「戴在手腕上的手绳」，避免文创挂饰被误判为手链品类。

  • 综合评分算法有设计：analyzeProduct 函数将利润、渠道适配、内容潜力、供应稳定性、风险、信息完整度 6 个维度按权重综合为 0-100 分，每个维度又有细分的加减分规则（如家居类易碎品额外扣分、饰品类缺材质说明扣分），不是拍脑袋的数字。

  • 内容测款方案具体可执行：getXhsContentPackage 和 getDouyinVideoPackage 不是泛泛的「做内容」，而是精确到每页图文结构、每段视频分镜的时间与文案、8 条互动引导问题、话题标签列表。用户拿到报告后可以直接照着拍。

  • 安全性规范完整：API Key 只保存在 Vercel/CloudBase 服务端环境变量，analyze-image.js 通过 process.env.DASHSCOPE_API_KEY 读取，不暴露到前端代码；前端 supabaseClient.js 仅读取 VITE_SUPABASE_URL 和 VITE_SUPABASE_ANON_KEY 公开密钥。文档中也明确说明了密钥不含在前端构建产物里。

  • 兜底设计周全：考虑到评委评审时 AI 接口可能不可用，项目提供了内置 6 个 demo 产品的「评委快速演示」模式，不依赖外部 API 也能跑通全流程；另有备用访问链接（腾讯云 CloudBase），应对 Vercel 被墙的情况。

  • UI 设计统一：暗色科技风配色（#08100d 底色 + emerald-300 高亮），使用 Tailwind CSS 的 glassmorphism 效果（backdrop-blur + border-white/10），卡片式布局，整体观感专业。

3. 当前问题

  • 单文件巨石架构（最严重问题）：App.jsx 超过 3300 行、260KB，将全部业务逻辑（品类模板、评分算法、内容生成、HTML 报告、API 调用、状态管理、UI 渲染）塞在一个文件里。这导致：

    • 代码完全不可维护，任何一个模块的修改都需要在这个巨型文件中定位
    • 无法做单元测试（没有任何 test 文件）
    • 没有组件复用，多个视图组件（CoverCard、Tab、ResultView 等）都定义在同一文件中而未拆分
    • 新增一个品类需要改动多处硬编码的逻辑

  • 文件重复冗余：

    • TradePilot-AI/AuthGate.jsx 与根目录 LoginGate.jsx 几乎完全一致（仅 title 文案有细微差别），却保留了两份，且 main.jsx 并未引入任何 AuthGate，说明其中一个是废弃代码
    • TradePilot-AI/README.md 与根目录 README.md 内容高度重复
    • TradePilot-AI/Demo-Guide.md、S1W1-Specs.md、S1W2-Skills.md 与 TradePilot-AI/docs/ 下的同名文件重复
    • TradePilot-AI/tailwind.config.js 与 TradePilot-AI/vite.config.js 内容几乎一样（tailwind config 内容被写入了 vite.config.js）

  • 品类逻辑过度硬编码：品类判断、内容模板、评分规则全部以 JavaScript 常量对象硬编码。每新增一个品类（如「母婴小商品」、「宠物用品」），需要改动十几个位置的代码。理想情况下应该将品类配置抽为 JSON/YAML 配置文件或数据库驱动。

  • AI 识别接口容错性不足：analyzeImageWithAI 函数仅捕获网络异常和超时，但图片 base64 尺寸过大、模型返回非标准 JSON 格式、API 额度耗尽等场景的错误提示对用户不够友好。

4. 建议

  • 拆分 App.jsx（优先级最高）：至少拆为以下模块：

    • constants/ — 品类模板、词库、评分规则等大数据常量
    • utils/analysis.js — analyzeProduct、inferProductIdentity 等纯函数
    • utils/report.js — generateHtmlReport、generateReportText 等报告生成
    • components/ — Header、CoverCard、OperateView、ResultView、HistoryView、PKView、ReviewView、DemoView、FloatingFeedback 等独立组件
    • hooks/ — useHistoryRecords、useImageAnalysis 等自定义 hooks

  • 引入 TypeScript：项目业务逻辑复杂度已经远超「一个 JSX 文件搞定」的范畴，加入 TS 后可以：

    • 为 product、result、report 等核心对象定义 interface
    • 避免字段拼写错误导致的运行时 bug
    • 重构时 IDE 能给出完整的类型提示

  • 清理冗余文件：删除根目录的 LoginGate.jsx（保留一处即可），删除重复的 README/Demo-Guide/Specs 文件，修复 vite.config.js 中错误的 tailwind 内容。

  • 修复 package.json 依赖分类：

    • 将 @vitejs/plugin-react、vite 移到 devDependencies
    • 确认 postcss 版本与 postcss.config.js 匹配
    • 添加 eslint、prettier 作为 devDependencies，配置基础规则

  • 品类配置外置化：将 categoryTemplates、productIdentityProfiles、platformKeywordPlan 等大数据常量抽取为独立的 JSON 或 YAML 配置文件，在构建时或运行时加载。这样新增品类只需修改配置文件，无需改动业务逻辑代码。

  • 引入轻量路由：使用 react-router-dom 替代手动 mode 状态切换，支持 URL 导航、浏览器前进后退、直接链接分享报告。

  • 完善 Supabase 集成：当前 supabaseClient.js 和 AuthGate.jsx 已经写好了基础框架，但实际应用中没有连线。建议至少实现：

    • 登录后在 HistoryView 中调用 supabase.from('product_history').select() 拉取云端数据
    • 保存报告时同时写入 localStorage 和 Supabase

  • 添加基础测试：至少为 analyzeProduct、inferProductIdentity、评分计算等纯函数添加单元测试（jest/vitest），确保品类判断和评分逻辑不会被意外破坏。

  • AI 接口增加降级策略：当阿里云百炼 API 返回非标准 JSON 或超时时，给出更明确的用户指引（如「请换一张更清晰的图片重试」），增加重试机制和请求队列。

5. 综合评价

这是一个领域认知深度远超工程规范水平的项目。

优点层面，团队对小商品进货决策场景有真实的理解——品类细分、利润测算、风险分层、内容测款指引都透露出实际做过电商或调研过该领域的痕迹。6 品类模板的分镜级内容指导（精确到秒级视频脚本和 8 页图文结构）和词库级品类识别引擎，是很多同类参赛项目不具备的。

问题层面，整个项目是「一个 3300 行 JSX 文件解决一切」的巨石架构。这在原型验证阶段勉强可行，但任何一个功能扩展都会牵一发动全身。缺少 TypeScript、测试、代码规范、文件结构清晰度等工程化基础设施，代码质量和可维护性处于较低水平。文档冗余（同一份 README 在 3 个不同路径出现）、废弃代码未清理（LoginGate/AuthGate 双份存在）、依赖管理不规范（devDependencies 与 dependencies 混放）等问题叠加，拉低了整体工程评价。

定位评价：作为一段时期内快速出原型的 Hackathon 项目，它在「解决什么问题」和「怎么解决」上表现非常出色；但作为可长期迭代的软件产品，工程架构需要一次彻底的重构。

## 1. 项目理解 我理解这个项目主要想解决： TradePilot AI（拿货搭子）是一个面向小商品进货决策与爆款测款的 AI 智能体，核心解决三个痛点： - **进货盲目**：新手卖家凭感觉拿货，缺少利润测算、风险判断、品类匹配等理性决策环节。 - **测款无方向**：拿货后不知道怎么在内容平台（小红书/抖音）测款，缺少文案、场景、标题等实操指导。 - **缺乏复盘**：一次进货判断做完就结束，没有将数据沉淀为可比较的产品库、PK 对比和测款复盘闭环。 项目围绕「产品信息采集 → 图片识别 → 利润测算 → 风险判断 → 内容测款建议 → 产品库沉淀 → 候选产品 PK → 测款复盘」构建了完整的业务工作流。技术侧使用 React + Vite + Tailwind CSS 构建前端，通过 Vercel Serverless Function 调用阿里云百炼视觉模型做图片识别，游客模式下用 localStorage 做产品数据持久化，预留学生用 Supabase 做用户鉴权和云端存储。 ## 2. 项目优点 - **领域知识深厚**：项目对「小商品进货」场景有深度理解，内置了饰品、发饰、家居生活、文创纸品、数码周边、低价日用 6 大品类模板，每个品类都有独立的评分逻辑、风险提示、内容文案结构、抖音脚本分镜，甚至是供应商沟通问题清单。这在同类参赛项目中非常少见。 - **品类识别引擎自成体系**：[App.jsx](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/App.jsx#L441-L570) 中的 `productIdentityProfiles` 是一个亮点，不是简单做品类关键词匹配，而是为每个细分品类定义了 strongTerms / weakTerms / allowedTerms / bannedTerms 四层词库，结合加权评分来做产品身份推断。比如能区分「挂在包上的木珠挂件」和「戴在手腕上的手绳」，避免文创挂饰被误判为手链品类。 - **综合评分算法有设计**：[analyzeProduct](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/App.jsx#L2109-L2199) 函数将利润、渠道适配、内容潜力、供应稳定性、风险、信息完整度 6 个维度按权重综合为 0-100 分，每个维度又有细分的加减分规则（如家居类易碎品额外扣分、饰品类缺材质说明扣分），不是拍脑袋的数字。 - **内容测款方案具体可执行**：[getXhsContentPackage](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/App.jsx#L1132-L1351) 和 [getDouyinVideoPackage](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/App.jsx#L1353-L1464) 不是泛泛的「做内容」，而是精确到每页图文结构、每段视频分镜的时间与文案、8 条互动引导问题、话题标签列表。用户拿到报告后可以直接照着拍。 - **安全性规范完整**：API Key 只保存在 Vercel/CloudBase 服务端环境变量，[analyze-image.js](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/api/analyze-image.js#L13) 通过 `process.env.DASHSCOPE_API_KEY` 读取，不暴露到前端代码；前端 [supabaseClient.js](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/supabaseClient.js#L3) 仅读取 `VITE_SUPABASE_URL` 和 `VITE_SUPABASE_ANON_KEY` 公开密钥。文档中也明确说明了密钥不含在前端构建产物里。 - **兜底设计周全**：考虑到评委评审时 AI 接口可能不可用，项目提供了内置 6 个 demo 产品的「评委快速演示」模式，不依赖外部 API 也能跑通全流程；另有备用访问链接（腾讯云 CloudBase），应对 Vercel 被墙的情况。 - **UI 设计统一**：暗色科技风配色（#08100d 底色 + emerald-300 高亮），使用 Tailwind CSS 的 glassmorphism 效果（backdrop-blur + border-white/10），卡片式布局，整体观感专业。 ## 3. 当前问题 - **单文件巨石架构（最严重问题）**：[App.jsx](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/App.jsx) 超过 3300 行、260KB，将全部业务逻辑（品类模板、评分算法、内容生成、HTML 报告、API 调用、状态管理、UI 渲染）塞在一个文件里。这导致： - 代码完全不可维护，任何一个模块的修改都需要在这个巨型文件中定位 - 无法做单元测试（没有任何 test 文件） - 没有组件复用，多个视图组件（CoverCard、Tab、ResultView 等）都定义在同一文件中而未拆分 - 新增一个品类需要改动多处硬编码的逻辑 - **文件重复冗余**： - `TradePilot-AI/AuthGate.jsx` 与根目录 `LoginGate.jsx` 几乎完全一致（仅 title 文案有细微差别），却保留了两份，且 [main.jsx](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/main.jsx#L3) 并未引入任何 AuthGate，说明其中一个是废弃代码 - `TradePilot-AI/README.md` 与根目录 `README.md` 内容高度重复 - `TradePilot-AI/Demo-Guide.md`、`S1W1-Specs.md`、`S1W2-Skills.md` 与 `TradePilot-AI/docs/` 下的同名文件重复 - `TradePilot-AI/tailwind.config.js` 与 `TradePilot-AI/vite.config.js` 内容几乎一样（tailwind config 内容被写入了 vite.config.js） - **品类逻辑过度硬编码**：品类判断、内容模板、评分规则全部以 JavaScript 常量对象硬编码。每新增一个品类（如「母婴小商品」、「宠物用品」），需要改动十几个位置的代码。理想情况下应该将品类配置抽为 JSON/YAML 配置文件或数据库驱动。 - **AI 识别接口容错性不足**：[analyzeImageWithAI](file:///d:/program/a/test/test/tradepilot-ai-wave2/TradePilot-AI/App.jsx#L2940-L3058) 函数仅捕获网络异常和超时，但图片 base64 尺寸过大、模型返回非标准 JSON 格式、API 额度耗尽等场景的错误提示对用户不够友好。 ## 4. 建议 - **拆分 App.jsx（优先级最高）**：至少拆为以下模块： - `constants/` — 品类模板、词库、评分规则等大数据常量 - `utils/analysis.js` — `analyzeProduct`、`inferProductIdentity` 等纯函数 - `utils/report.js` — `generateHtmlReport`、`generateReportText` 等报告生成 - `components/` — `Header`、`CoverCard`、`OperateView`、`ResultView`、`HistoryView`、`PKView`、`ReviewView`、`DemoView`、`FloatingFeedback` 等独立组件 - `hooks/` — `useHistoryRecords`、`useImageAnalysis` 等自定义 hooks - **引入 TypeScript**：项目业务逻辑复杂度已经远超「一个 JSX 文件搞定」的范畴，加入 TS 后可以： - 为 product、result、report 等核心对象定义 interface - 避免字段拼写错误导致的运行时 bug - 重构时 IDE 能给出完整的类型提示 - **清理冗余文件**：删除根目录的 `LoginGate.jsx`（保留一处即可），删除重复的 README/Demo-Guide/Specs 文件，修复 `vite.config.js` 中错误的 tailwind 内容。 - **修复 package.json 依赖分类**： - 将 `@vitejs/plugin-react`、`vite` 移到 `devDependencies` - 确认 `postcss` 版本与 `postcss.config.js` 匹配 - 添加 `eslint`、`prettier` 作为 devDependencies，配置基础规则 - **品类配置外置化**：将 `categoryTemplates`、`productIdentityProfiles`、`platformKeywordPlan` 等大数据常量抽取为独立的 JSON 或 YAML 配置文件，在构建时或运行时加载。这样新增品类只需修改配置文件，无需改动业务逻辑代码。 - **引入轻量路由**：使用 `react-router-dom` 替代手动 `mode` 状态切换，支持 URL 导航、浏览器前进后退、直接链接分享报告。 - **完善 Supabase 集成**：当前 `supabaseClient.js` 和 `AuthGate.jsx` 已经写好了基础框架，但实际应用中没有连线。建议至少实现： - 登录后在 `HistoryView` 中调用 `supabase.from('product_history').select()` 拉取云端数据 - 保存报告时同时写入 localStorage 和 Supabase - **添加基础测试**：至少为 `analyzeProduct`、`inferProductIdentity`、评分计算等纯函数添加单元测试（jest/vitest），确保品类判断和评分逻辑不会被意外破坏。 - **AI 接口增加降级策略**：当阿里云百炼 API 返回非标准 JSON 或超时时，给出更明确的用户指引（如「请换一张更清晰的图片重试」），增加重试机制和请求队列。 ## 5. 综合评价 这是一个**领域认知深度远超工程规范水平的项目**。 优点层面，团队对小商品进货决策场景有真实的理解——品类细分、利润测算、风险分层、内容测款指引都透露出实际做过电商或调研过该领域的痕迹。6 品类模板的分镜级内容指导（精确到秒级视频脚本和 8 页图文结构）和词库级品类识别引擎，是很多同类参赛项目不具备的。 问题层面，整个项目是「一个 3300 行 JSX 文件解决一切」的巨石架构。这在原型验证阶段勉强可行，但任何一个功能扩展都会牵一发动全身。缺少 TypeScript、测试、代码规范、文件结构清晰度等工程化基础设施，代码质量和可维护性处于较低水平。文档冗余（同一份 README 在 3 个不同路径出现）、废弃代码未清理（LoginGate/AuthGate 双份存在）、依赖管理不规范（devDependencies 与 dependencies 混放）等问题叠加，拉低了整体工程评价。 **定位评价**：作为一段时期内快速出原型的 Hackathon 项目，它在「解决什么问题」和「怎么解决」上表现非常出色；但作为可长期迭代的软件产品，工程架构需要一次彻底的重构。
Jyoti commented 2026-05-15 23:07:45 +08:00
Owner
Copy link

感谢你的详细评测，反馈非常具体，也指出了当前原型从“能跑通”走向“可长期维护产品”时需要补齐的工程化问题。

你提到的几点我基本认可，尤其是：

  1. App.jsx 过于集中

    当前版本为了在 S1W2 阶段快速跑通原型，把品类模板、评分逻辑、内容生成、报告下载、状态管理和 UI 渲染都集中在 App.jsx 中。这样确实有利于快速验证业务闭环，但不利于后续维护和扩展。后续会优先拆分为：

    • constants/：品类模板、评分规则、词库等配置
    • utils/analysis.js：产品分析、身份识别、评分计算
    • utils/report.js：HTML 报告和文本报告生成
    • components/：Header、产品表单、结果视图、产品库、PK、复盘等组件
    • hooks/：图片识别、产品库记录、报告状态等逻辑

  2. 文件结构和重复文件需要清理

    目前确实存在部分文档和组件在根目录与 TradePilot-AI/ 目录中重复的问题，这是为了比赛仓库和主代码仓库同步时保留材料造成的。后续会统一保留一套规范结构，减少重复 README、Demo Guide、Specs 等文件，让评委和后续开发者更容易理解项目目录。

  3. TypeScript、测试和工程规范值得补充

    项目目前使用 JSX 快速开发，适合原型阶段。但随着产品对象、报告对象、复盘数据、评分结果等结构越来越复杂，引入 TypeScript 确实可以减少字段拼写和数据结构不一致导致的问题。后续也会考虑为 analyzeProduct、inferProductIdentity、评分计算等核心纯函数补充基础测试，避免新增品类时破坏原有逻辑。

  4. 品类配置应该外置

    你提到“品类逻辑过度硬编码”这一点很关键。当前项目已经有品类识别和串模板修复逻辑，但确实散落在业务代码中。后续会将 categoryTemplates、productIdentityProfiles、platformKeywordPlan 等内容抽离为 JSON/YAML 配置文件，让新增品类时主要修改配置，而不是频繁改动主业务逻辑。

  5. AI 接口异常处理还可以继续优化

    当前项目已经加入图片压缩、备用访问链接和部分错误提示，但在模型返回非标准 JSON、超时、大图上传、网络不稳定等情况下，用户体验还可以继续增强。后续会增加更明确的降级策略，例如保留图片预览、引导用户手动补充信息、增加重试机制和更友好的错误提示。

整体来说，你的反馈让我更清楚地看到：当前版本已经跑通了“进货判断—内容测款—产品库—候选 PK—测款复盘”的业务闭环，但工程结构还需要从原型式开发进一步升级为可长期维护的产品架构。

后续我会优先处理三类问题：

  • 拆分 App.jsx，提升代码可维护性；
  • 清理重复文件和目录结构；
  • 将品类模板、评分规则和报告生成逻辑配置化、模块化。

再次感谢你的认真评测，这些建议对项目后续迭代非常有帮助。

感谢你的详细评测，反馈非常具体，也指出了当前原型从“能跑通”走向“可长期维护产品”时需要补齐的工程化问题。 你提到的几点我基本认可，尤其是： 1. **App.jsx 过于集中** 当前版本为了在 S1W2 阶段快速跑通原型，把品类模板、评分逻辑、内容生成、报告下载、状态管理和 UI 渲染都集中在 App.jsx 中。这样确实有利于快速验证业务闭环，但不利于后续维护和扩展。后续会优先拆分为： - `constants/`：品类模板、评分规则、词库等配置 - `utils/analysis.js`：产品分析、身份识别、评分计算 - `utils/report.js`：HTML 报告和文本报告生成 - `components/`：Header、产品表单、结果视图、产品库、PK、复盘等组件 - `hooks/`：图片识别、产品库记录、报告状态等逻辑 2. **文件结构和重复文件需要清理** 目前确实存在部分文档和组件在根目录与 `TradePilot-AI/` 目录中重复的问题，这是为了比赛仓库和主代码仓库同步时保留材料造成的。后续会统一保留一套规范结构，减少重复 README、Demo Guide、Specs 等文件，让评委和后续开发者更容易理解项目目录。 3. **TypeScript、测试和工程规范值得补充** 项目目前使用 JSX 快速开发，适合原型阶段。但随着产品对象、报告对象、复盘数据、评分结果等结构越来越复杂，引入 TypeScript 确实可以减少字段拼写和数据结构不一致导致的问题。后续也会考虑为 `analyzeProduct`、`inferProductIdentity`、评分计算等核心纯函数补充基础测试，避免新增品类时破坏原有逻辑。 4. **品类配置应该外置** 你提到“品类逻辑过度硬编码”这一点很关键。当前项目已经有品类识别和串模板修复逻辑，但确实散落在业务代码中。后续会将 `categoryTemplates`、`productIdentityProfiles`、`platformKeywordPlan` 等内容抽离为 JSON/YAML 配置文件，让新增品类时主要修改配置，而不是频繁改动主业务逻辑。 5. **AI 接口异常处理还可以继续优化** 当前项目已经加入图片压缩、备用访问链接和部分错误提示，但在模型返回非标准 JSON、超时、大图上传、网络不稳定等情况下，用户体验还可以继续增强。后续会增加更明确的降级策略，例如保留图片预览、引导用户手动补充信息、增加重试机制和更友好的错误提示。 整体来说，你的反馈让我更清楚地看到：当前版本已经跑通了“进货判断—内容测款—产品库—候选 PK—测款复盘”的业务闭环，但工程结构还需要从原型式开发进一步升级为可长期维护的产品架构。 后续我会优先处理三类问题： - 拆分 App.jsx，提升代码可维护性； - 清理重复文件和目录结构； - 将品类模板、评分规则和报告生成逻辑配置化、模块化。 再次感谢你的认真评测，这些建议对项目后续迭代非常有帮助。
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Jyoti/tradepilot-ai-wave2#2
No description provided.