sync: d8d-iterate git 变更自动检测 + d8d-dev 更新 #21
@@ -66,11 +66,11 @@
|
||||
}
|
||||
```
|
||||
- 标记:Epic 0 完成后此文件才可生效(项目目录需先存在)
|
||||
- ⛔ **HMR 降级策略(备选)**:配置了 `allowedDevOrigins` 后,外网域名的 HMR 通常可以正常工作。仅在以下情况下降级到生产模式:
|
||||
- 配置了 `allowedDevOrigins` 后 HMR 仍失败
|
||||
- 需要最大化测试稳定性(生产模式无 HMR 干扰)
|
||||
|
||||
降级步骤(`next start` 替代 `next dev`):
|
||||
- ⛔ **HMR 降级策略(备选)**:配置了 `allowedDevOrigins` 后,外网域名的 HMR 通常可以正常工作。仅在以下情况下降级到生产模式:
|
||||
- 配置了 `allowedDevOrigins` 后 HMR 仍失败
|
||||
- 需要最大化测试稳定性(生产模式无 HMR 干扰)
|
||||
|
||||
降级步骤(`next start` 替代 `next dev`):
|
||||
```bash
|
||||
npx next build
|
||||
pm2 stop app && pm2 delete app
|
||||
@@ -188,37 +188,37 @@
|
||||
- Next.js 可能需要清缓存:删除 `app/admin/.next` 后重启
|
||||
|
||||
**注意事项**:
|
||||
|
||||
当通过外网域名(如 `*.dev.d8d.fun`)访问 Next.js 开发服务器时,必须在 `next.config.ts` 中配置 `allowedDevOrigins`,否则会出现 "Invalid Host header" 错误。
|
||||
|
||||
**配置示例**:
|
||||
```typescript
|
||||
// next.config.ts
|
||||
import type { NextConfig } from "next";
|
||||
|
||||
const nextConfig: NextConfig = {
|
||||
allowedDevOrigins: [
|
||||
"*.dev.d8d.fun",
|
||||
"localhost",
|
||||
],
|
||||
};
|
||||
|
||||
export default nextConfig;
|
||||
```
|
||||
|
||||
**配置后重启服务**:
|
||||
```bash
|
||||
pm2 restart vividspark
|
||||
```
|
||||
|
||||
详见 `./reference/platform-nextjs.md` §10
|
||||
|
||||
4.9. **MinIO 外网地址注入(⛔ 强制)**
|
||||
- 如果使用 localhost fallback(步骤 4.6 的 Step 3 结果),.env.local 值写 `http://localhost:3001`
|
||||
- 此步骤创建的 .env.local 不应提交到 git(应在 .gitignore 中排除)
|
||||
- 更新 pipeline-context.md 记录注入状态
|
||||
|
||||
4.8. **MinIO 外网地址注入(⛔ 强制)**
|
||||
4.8. **Next.js allowedDevOrigins 配置(⛔ 外网域名访问时强制)**
|
||||
|
||||
当通过外网域名(如 `*.dev.d8d.fun`)访问 Next.js 开发服务器时,必须在 `next.config.ts` 中配置 `allowedDevOrigins`,否则会出现 "Invalid Host header" 错误。
|
||||
|
||||
**配置示例**:
|
||||
```typescript
|
||||
// next.config.ts
|
||||
import type { NextConfig } from "next";
|
||||
|
||||
const nextConfig: NextConfig = {
|
||||
allowedDevOrigins: [
|
||||
"*.dev.d8d.fun",
|
||||
"localhost",
|
||||
],
|
||||
};
|
||||
|
||||
export default nextConfig;
|
||||
```
|
||||
|
||||
**配置后重启服务**:
|
||||
```bash
|
||||
pm2 restart vividspark
|
||||
```
|
||||
|
||||
详见 `./reference/platform-nextjs.md` §10
|
||||
|
||||
4.9. **MinIO 外网地址注入(⛔ 强制)**
|
||||
|
||||
检测容器环境变量 `MINIO_HOST`,将外网地址注入到 `.env` 中的 `S3_PUBLIC_URL`:
|
||||
|
||||
|
||||
@@ -23,11 +23,14 @@ description: '需求迭代自动化编排技能。智能检测项目状态,分
|
||||
## 使用方式
|
||||
|
||||
```
|
||||
/d8d-iterate <变更描述>
|
||||
/d8d-iterate <变更描述> # 提供描述时按描述分析
|
||||
/d8d-iterate # 无描述时自动检测 git 变更并推断
|
||||
|
||||
示例:
|
||||
/d8d-iterate 增加多城市批量任务调度功能
|
||||
/d8d-iterate 修复搜索结果为空的问题
|
||||
/d8d-iterate 重构数据模型为多城市支持
|
||||
/d8d-iterate 回归验证所有功能
|
||||
/d8d-iterate # 自动检测最近代码变更,智能路由
|
||||
/d8d-iterate 验证一下 # 模糊描述也能正确路由
|
||||
```
|
||||
|
||||
@@ -170,3 +170,58 @@ IF design_file_changed == true:
|
||||
```
|
||||
|
||||
将项目类型写入 `iterate-checkpoint.md`。
|
||||
|
||||
### 3.6 代码变更扫描(⭐ 新增)
|
||||
|
||||
扫描当前代码变更,用于辅助变更分析和路由决策。
|
||||
|
||||
**检测流程**:
|
||||
|
||||
```
|
||||
1. git status --short → 检测未提交的变更文件列表
|
||||
2. git diff HEAD~1 --stat → 检测最近一次提交的变更文件
|
||||
3. git log --oneline -5 → 获取最近 5 次提交记录
|
||||
4. 汇总变更文件,按目录分类:
|
||||
- src/app/api/ → API 路由变更
|
||||
- src/server/ → 后端逻辑变更(provider、service 等)
|
||||
- src/components/ → UI 组件变更
|
||||
- prisma/ → 数据模型变更
|
||||
- 其他文件
|
||||
```
|
||||
|
||||
**智能分类规则**:
|
||||
|
||||
```
|
||||
IF 变更文件数 = 0 且无未提交变更:
|
||||
→ code_changed: false
|
||||
|
||||
IF 变更文件数 1-3 且集中在同一模块:
|
||||
→ code_changed: true, change_scale: small
|
||||
|
||||
IF 变更文件数 > 3 或跨多模块:
|
||||
→ code_changed: true, change_scale: medium/large
|
||||
|
||||
IF 涉及数据模型(prisma/):
|
||||
→ 额外标记 schema_changed: true
|
||||
```
|
||||
|
||||
**输出写入 iterate-context.md**:
|
||||
|
||||
```markdown
|
||||
### 代码变更状态
|
||||
code_changed: true/false
|
||||
change_scale: none | small | medium | large
|
||||
schema_changed: true/false
|
||||
|
||||
最近提交:
|
||||
| 提交 | 描述 | 文件数 |
|
||||
|------|------|--------|
|
||||
| abc1234 | fix: xxx | 3 |
|
||||
|
||||
变更文件:
|
||||
| 文件 | 变更类型 | 分类 |
|
||||
|------|---------|------|
|
||||
| src/server/providers/amap-provider.ts | modified | provider |
|
||||
```
|
||||
|
||||
**无 git 仓库时**:跳过此步骤,`code_changed: unknown`。
|
||||
|
||||
@@ -35,6 +35,35 @@
|
||||
|
||||
**混合类型处理**:如果包含多种意图,按优先级 feature > refactor > bugfix > design 取主要类型,次要类型记录为附加任务。
|
||||
|
||||
**⭐ 自动推断(用户描述模糊或未提供时)**:
|
||||
|
||||
当用户描述为以下情况时,触发代码变更状态推断:
|
||||
- 未提供描述(空字符串)
|
||||
- 极短描述(<10字符,如"验证"、"看看"、"跑一下")
|
||||
- 描述不含任何上表分类关键词
|
||||
|
||||
推断优先级:用户描述关键词 > 代码变更状态推断
|
||||
|
||||
推断逻辑(读取 iterate-context.md 的代码变更状态):
|
||||
|
||||
```
|
||||
IF code_changed == false:
|
||||
→ regression(代码没改,只需验证现有功能)
|
||||
|
||||
IF code_changed == true:
|
||||
→ 分析变更文件路径和 commit message 自动分类:
|
||||
- change_scale=small + 集中在后端(provider/service) → bugfix
|
||||
- 涉及新文件/新路由/新组件 → feature
|
||||
- 跨多模块 + commit 含"重构/优化/迁移" → refactor
|
||||
- 仅样式/布局文件变更 → design
|
||||
- 无法判断 → 默认 regression + 在报告中说明推断理由
|
||||
|
||||
IF code_changed == unknown(非 git 仓库):
|
||||
→ 跳过推断,回退到询问用户
|
||||
```
|
||||
|
||||
将推断结果写入 iterate-context.md 并说明推断理由。
|
||||
|
||||
### Step 1.3: 影响范围评估
|
||||
|
||||
根据变更类型,评估影响范围:
|
||||
|
||||
@@ -132,7 +132,7 @@ phase-05-verify: completed | skipped | failed
|
||||
|
||||
**输入**: 用户通过 `/d8d-iterate <描述>` 提供的变更需求。
|
||||
|
||||
如果用户未提供描述,询问:请描述您需要的变更。
|
||||
如果用户未提供描述或描述模糊(<10字符且无分类关键词),**不询问用户**,Phase 0 扫描时自动检测 git 变更,Phase 1 基于代码变更状态自动推断变更类型。仅在推断信心低时才询问用户确认。
|
||||
|
||||
### Step 1: 执行 Phase 0 — 项目状态扫描
|
||||
|
||||
|
||||
Reference in New Issue
Block a user