Compare commits
7 Commits
599bb933b8
...
d5426c980f
| Author | SHA1 | Date |
|---|---|---|
|
|
d5426c980f | |
|
|
c3f2c0f136 | |
|
|
919ac890a9 | |
|
|
534aa4224c | |
|
|
8a43ba7717 | |
|
|
b52a3fba4a | |
|
|
dd6b49e199 |
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
name: factory-release
|
||||
description: Use when the user explicitly asks to release the factory backend, run its release workflow, or bump its deployed version.
|
||||
---
|
||||
|
||||
# 发布 Factory 后端
|
||||
|
||||
仅在用户明确要求后端发版、release 或提升部署版本时执行本流程。普通代码修改、提交或推送不触发发版。
|
||||
|
||||
严格按以下顺序执行:
|
||||
|
||||
1. 确认目标是当前 `factory` 后端。若用户要求发布 `ehs_web` 前端,改读 `.codex/memory/reference_ehs_web_release.md`。
|
||||
2. 执行 `git status --short`,确认工作区状态。发布提交只能包含 `changelog.md` 和 `server/settings.py`;不得混入其他已修改或未跟踪文件。
|
||||
3. 执行 `bash update_changelog.sh`,从脚本输出读取形如 `3.1.YYYYMMDDHH` 的版本号,记为 `<VER>`。不得自行编造或改写版本号。
|
||||
4. 把 `server/settings.py` 中唯一权威版本字段 `SYS_VERSION` 更新为 `<VER>`。
|
||||
5. 读取 `changelog.md` 顶部约 20 行,确认标题是 `## <VER>`,且自上一个 tag 起的提交分类合理。出现重复段、明显漏项或无关内容时,先向用户确认,不得继续打 tag。
|
||||
6. 再次检查 diff,只暂存 `changelog.md` 和 `server/settings.py`。
|
||||
7. 提交信息使用 `release: <VER>`,不添加工具或模型专属署名。
|
||||
8. 创建无 `v` 前缀的 tag:`git tag <VER>`。
|
||||
9. 推送当前分支到 `origin`,成功后再执行 `git push origin <VER>`。逐步检查结果,不用命令链掩盖中间失败。
|
||||
10. 汇报 `<VER>`、changelog 包含的提交类别、commit hash、tag 名,以及分支和 tag 的推送结果。
|
||||
|
||||
若提交、tag 或推送中途失败,先检查实际 Git 状态。任何会重写历史或删除远端 tag 的回退操作,都必须先取得用户明确授权。
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
# Factory 项目记忆索引
|
||||
|
||||
- [前端路由由后端下发](feedback_routing.md):新增 `ehs_web` 页面时不要修改静态路由表。
|
||||
- [scripts 目录脚本不入库](feedback_scripts_gitignore.md):一次性回刷脚本不得强制加入 Git。
|
||||
- [发版只在明确要求时执行](feedback_version_bump.md):普通改动不自动 bump 或 release。
|
||||
- [后端配套前端](project_frontend_ehs_web.md):后端 API 改动时检查 `../ehs_web` 及统计页面惯例。
|
||||
- [生产数据只读验证](project_gx_db_access.md):涉及真实数据形态时的安全查询原则。
|
||||
- [合批原料字段历史问题](project_material_ofrom_merge_bug.md):`material_ofrom` 不一致的既有排查结论。
|
||||
- [前端独立发版流程](reference_ehs_web_release.md):发布 `ehs_web` 时使用。
|
||||
- [项目 Python 虚拟环境](reference_python_venv.md):运行 Django、pytest 和脚本时使用。
|
||||
- [两个 WebView 套壳 App](reference_wrapper_apps.md):修改 h5x 与扫码、返回键交互时使用。
|
||||
|
||||
这些文件记录的是长期约定或历史上下文。执行任务前应结合当前代码和数据重新验证,尤其不要把历史缺陷结论直接当成当前故障原因。
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# ehs_web 路由由后端下发
|
||||
|
||||
`ehs_web` 使用后端下发的动态菜单和路由。新增管理页面时,不要向 `src/config/route.js` 添加条目;该文件中的既有静态路由属于历史或局部用法,不能作为新页面的默认范例。
|
||||
|
||||
通常只需:
|
||||
|
||||
- 创建 `src/views/<module>/<name>.vue`。
|
||||
- 补充 `src/api/model/<module>.js` 中的接口。
|
||||
- 在后端菜单与权限配置中设置组件相对路径和权限码。
|
||||
|
||||
若页面未出现在菜单中,应检查后端菜单、权限与组件路径配置,不要用新增静态路由规避问题。
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# scripts 目录脚本不入库
|
||||
|
||||
仓库 `.gitignore` 中的 `scripts/*.py` 是有意设置的:`correct_*` 等一次性回刷、修数脚本只在本地或服务器按需运行,不进入版本库。
|
||||
|
||||
编写这类脚本后:
|
||||
|
||||
- 正常保留在本地工作区。
|
||||
- 提交时不要执行 `git add -f`。
|
||||
- 不因仓库中存在少量历史已跟踪脚本而推断新脚本也应提交。
|
||||
|
||||
只有用户明确要求某个脚本入库时,才可改变这一规则。
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# 发版只在用户明确要求时执行
|
||||
|
||||
不要在每轮代码修改完成后自动提升版本号、生成 release commit 或打 tag。版本对应实际部署,多轮改动可以合并到一次发版。
|
||||
|
||||
普通任务完成后可以正常提交代码,但只有用户明确说“发版”“走 release”或“bump 版本”时,才读取并执行 `.agents/skills/release/SKILL.md`。
|
||||
|
||||
后端与前端有各自独立的发版流程;后端 release skill 不适用于 `../ehs_web`。
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# Factory 配套前端 ehs_web
|
||||
|
||||
当前仓库是 Django 后端,配套 Vue 前端位于 `../ehs_web`(通常解析为 `D:\projects\ehs_web`,也可从 `factory.code-workspace` 核对)。
|
||||
|
||||
修改 serializer 字段、API 返回结构或接口行为后,应主动检查前端中消费该接口的:
|
||||
|
||||
- `src/views/` 页面。
|
||||
- `src/api/model/` 接口定义。
|
||||
|
||||
路由和菜单规则见 [前端路由由后端下发](feedback_routing.md)。
|
||||
|
||||
统计页面现有惯例可参考 `src/views/statistics/good_check_gx2.vue` 和 `zt_batch_gx.vue`:
|
||||
|
||||
- Options API 与 `el-container` 布局。
|
||||
- 复杂查询通过 `$API.wpm.batchstquery` 调用后端 `ComplexQueryMixin`。
|
||||
- `querys` 使用外层 OR、内层 AND 的 `{field, compare, value}` 条件。
|
||||
- JSONField 中文键常直接从 `scope.row.data` 读取。
|
||||
- 表格导出使用项目现有 `$XLSX` 封装。
|
||||
- JSONField 键的子串匹配使用 `icontains`;`contains` 表示 JSON 包含语义。
|
||||
|
||||
这些是现有实现惯例,不替代对当前页面和接口代码的检查。
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
# 生产数据只读验证
|
||||
|
||||
各工厂 PostgreSQL 连接参数保存在本机被 Git 忽略的配置中。涉及批次谱系、统计口径或真实数据形态时,可以在任务确有需要且用户允许的范围内做只读抽样查询。
|
||||
|
||||
安全要求:
|
||||
|
||||
- 从本地忽略配置读取连接参数,不在文档、脚本、命令记录或提交中复制凭据。
|
||||
- 数据库会话显式设为只读。
|
||||
- 禁止执行 INSERT、UPDATE、DELETE、DDL、修数或其他写操作,除非用户针对该操作另行明确授权。
|
||||
- 临时查询脚本放在不会提交的本地位置。
|
||||
- Windows 中文输出需要时设置 UTF-8 编码。
|
||||
|
||||
真实数据可能包含拆合批循环、自环边和期初断头批。修改统计或谱系算法前,优先用少量只读样本验证数据假设。
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# 合批原料 material_ofrom 历史排查
|
||||
|
||||
## 历史现象
|
||||
|
||||
曾出现合批或生产流转后,批次签带显示的原料类型与实物板段棒签不一致。同一工序可能存在多条并行原料输入,因此也可能发生真实混料。该问题当时决定暂缓,只有再次出现并取得可复现样本时再继续调查。
|
||||
|
||||
## 已确认的代码风险
|
||||
|
||||
`WMaterial.locked_get_or_create`(`apps/utils/models.py`)命中既有行时直接返回,不会应用 `defaults`。在 `apps/wpm/services.py` 的合批或流转逻辑中:
|
||||
|
||||
- `material_ofrom`、`batch_ofrom`、`number_from` 只放在 `defaults`。
|
||||
- 定位既有行的键不包含 `material_ofrom`。
|
||||
|
||||
因此,一旦命中相同业务键的旧行,后续不同原料流入时,`material_ofrom` 可能继续保留首次建行时的值。该字段又是单个外键,结构上无法表达混料。签带展示值来自 serializer 中的 `material_ofrom_name`。
|
||||
|
||||
## 历史样本结论
|
||||
|
||||
当时抽样数据中的相关 `WMaterial` 行已经归零,来源记录也指向原有材料;实物板段号在当前 WPM 相关表中没有找到。由此推测,实物棒签的材料源和板段号可能来自上游拉丝或滚圆子系统,单靠当前库无法闭环证明。
|
||||
|
||||
## 下次接续
|
||||
|
||||
再次出现时应先取得一个“实物棒签材料与批次签带材料不一致、且两者来源可在同一系统追踪”的批次样本,然后:
|
||||
|
||||
1. 确认实物棒签由哪个系统和表生成。
|
||||
2. 用只读查询验证流转前后定位键是否命中旧行。
|
||||
3. 区分真实混料、上游标签来源和 `defaults` 未更新这三种原因。
|
||||
4. 在复现前不要直接修改字段结构或流转逻辑。
|
||||
|
||||
查询时遵守 [生产数据只读验证](project_gx_db_access.md)。
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
# ehs_web 前端独立发版流程
|
||||
|
||||
`../ehs_web` 有独立于后端的发版流程。`.agents/skills/release/SKILL.md` 只适用于当前 `factory` 后端。
|
||||
|
||||
前端发版要点:
|
||||
|
||||
1. 权威版本号位于 `src/config/index.js` 的 `APP_VER`。
|
||||
2. 在前端仓库运行 `update_changelog.sh`,使用脚本生成的 `3.1.YYYYMMDDHH` 版本号。若上一个 tag 过旧,可向脚本传入合适的起点 ref,并检查提交分类。
|
||||
3. 把 `APP_VER` 更新为相同版本。
|
||||
4. 只暂存前端的 `changelog.md` 和 `src/config/index.js`。
|
||||
5. 提交信息使用 `release: <VER>`,tag 使用无 `v` 前缀的 `<VER>`。
|
||||
6. 推送到前端仓库配置的 `coding` 远端,而不是默认假设使用 `origin`。
|
||||
|
||||
前端 `package.json` 中的旧 `version` 字段不是当前权威版本。仍须遵守“只有用户明确要求才发版”的约束。
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
# Factory 项目 Python 解释器
|
||||
|
||||
项目根目录包含 Windows 虚拟环境 `.venv`。运行 `manage.py`、pytest 或项目 Python 脚本时使用:
|
||||
|
||||
```powershell
|
||||
D:\projects\factory\.venv\Scripts\python.exe manage.py check
|
||||
```
|
||||
|
||||
从 Git Bash 调用时可使用:
|
||||
|
||||
```bash
|
||||
/d/projects/factory/.venv/Scripts/python.exe manage.py check
|
||||
```
|
||||
|
||||
不要直接依赖系统 `python`,因为系统环境可能缺少项目依赖。
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# Web 前端的两个套壳 App
|
||||
|
||||
`ehs_web` 的 h5x 页面还由两个 WebView 壳工程加载:
|
||||
|
||||
- 原生 Android 壳:`C:\Users\caoqi\AndroidStudioProjects\BxErp`,包名 `com.example.bxerp`。核心入口是 `app/src/main/java/com/example/bxerp/MainActivity.kt`,通过 `window.Android` 暴露扫码能力,常用交互为 `Android.openScanner()` 和页面回调 `onScanResult(data)`。
|
||||
- uni-app 壳:`D:\projects\mp_shell`,Vue 3/HBuilderX 工程,应用名“光芯ERP”。`pages/index/index.vue` 使用 `<web-view>` 加载 h5x,并处理返回键与状态栏适配。
|
||||
|
||||
修改 h5x 的扫码、返回键或 WebView 消息交互时,应检查这两个壳的约定。工程位置和加载地址可能随部署变化,操作前以当前本地代码为准。
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# Factory 项目协作约定
|
||||
|
||||
## 项目结构
|
||||
|
||||
- 当前仓库是 Django 后端。
|
||||
- 配套 Vue 前端位于 `../ehs_web`。修改 serializer 字段、API 返回结构或接口行为时,检查并同步对应的前端页面和 `src/api/model/` 接口定义。
|
||||
- `ehs_web` 的菜单和路由由后端动态下发。新增页面时不要修改 `src/config/route.js`;页面组件、菜单和权限应按后端配置衔接。
|
||||
|
||||
## 本地执行
|
||||
|
||||
- 在 Windows 下运行 Django、pytest 或其他 Python 命令时,使用项目虚拟环境:`D:\projects\factory\.venv\Scripts\python.exe`。不要依赖系统 Python。
|
||||
- `scripts/*.py` 是有意忽略的一次性回刷或修数脚本。未经用户明确要求,不得用 `git add -f` 强制提交。
|
||||
|
||||
## 数据安全
|
||||
|
||||
- 涉及生产数据验证时,只允许执行只读查询;写入、修数或结构变更必须取得用户针对该操作的明确授权。
|
||||
- 数据库连接参数从本机已忽略的配置读取。不得把用户名、密码、连接串或可直接复用的带凭据命令写入文档、skill、提交信息或源码。
|
||||
|
||||
## 发版
|
||||
|
||||
- 不要在普通修改完成后自动提升版本号、打 tag 或发版。
|
||||
- 只有用户明确要求“发版”“release”或“bump 版本”时,才使用 `.agents/skills/release/SKILL.md`。
|
||||
- 前端 `ehs_web` 有独立发版流程,不要套用后端 release 流程。
|
||||
|
||||
## 按需项目知识
|
||||
|
||||
- 详细项目背景、历史反馈和排障记录见 `.codex/memory/MEMORY.md`。
|
||||
- 只在任务相关时读取对应 memory 文件,避免把历史问题误当成当前事实。
|
||||
|
|
@ -1,3 +1,60 @@
|
|||
from django.test import TestCase
|
||||
from types import SimpleNamespace
|
||||
from unittest.mock import MagicMock, patch
|
||||
|
||||
# Create your tests here.
|
||||
from django.test import SimpleTestCase
|
||||
from rest_framework.test import APIRequestFactory
|
||||
|
||||
from apps.wf.views import TicketViewSet
|
||||
|
||||
|
||||
class TicketAvailableActionsTests(SimpleTestCase):
|
||||
def setUp(self):
|
||||
self.request = APIRequestFactory().get('/api/wf/ticket/1/available_actions/')
|
||||
self.request.user = SimpleNamespace(id='user-1')
|
||||
self.view = TicketViewSet()
|
||||
self.ticket = SimpleNamespace(in_add_node=False)
|
||||
self.view.get_object = MagicMock(return_value=self.ticket)
|
||||
|
||||
@patch('apps.wf.views.TransitionSerializer')
|
||||
@patch('apps.wf.views.WfService.get_ticket_transitions')
|
||||
@patch('apps.wf.views.WfService.ticket_handle_permission_check')
|
||||
def test_returns_transitions_when_user_can_handle(
|
||||
self, permission_check, get_transitions, serializer):
|
||||
permission_check.return_value = {
|
||||
'permission': True,
|
||||
'need_accept': False,
|
||||
'msg': '',
|
||||
}
|
||||
transitions = MagicMock()
|
||||
transitions.select_related.return_value = transitions
|
||||
get_transitions.return_value = transitions
|
||||
serializer.return_value.data = [{'id': 'transition-1', 'name': '同意'}]
|
||||
|
||||
response = self.view.available_actions(self.request)
|
||||
|
||||
self.assertTrue(response.data['permission'])
|
||||
self.assertFalse(response.data['need_accept'])
|
||||
self.assertEqual(
|
||||
response.data['transitions'],
|
||||
[{'id': 'transition-1', 'name': '同意'}],
|
||||
)
|
||||
|
||||
@patch('apps.wf.views.TransitionSerializer')
|
||||
@patch('apps.wf.views.WfService.get_ticket_transitions')
|
||||
@patch('apps.wf.views.WfService.ticket_handle_permission_check')
|
||||
def test_hides_transitions_and_requests_accept_for_active_distribution(
|
||||
self, permission_check, get_transitions, serializer):
|
||||
permission_check.return_value = {
|
||||
'permission': False,
|
||||
'need_accept': True,
|
||||
'msg': '需要先接单再处理',
|
||||
}
|
||||
|
||||
response = self.view.available_actions(self.request)
|
||||
|
||||
self.assertFalse(response.data['permission'])
|
||||
self.assertTrue(response.data['need_accept'])
|
||||
self.assertEqual(response.data['message'], '需要先接单再处理')
|
||||
self.assertEqual(response.data['transitions'], [])
|
||||
get_transitions.assert_not_called()
|
||||
serializer.assert_not_called()
|
||||
|
|
|
|||
|
|
@ -363,6 +363,34 @@ class TicketViewSet(CreateUpdateCustomMixin, CreateModelMixin, ListModelMixin, R
|
|||
transitions = WfService.get_ticket_transitions(ticket)
|
||||
return Response(TransitionSerializer(instance=transitions.select_related('source_state', 'destination_state'), many=True).data)
|
||||
|
||||
@action(methods=['get'], detail=True, perms_map={'get': '*'})
|
||||
def available_actions(self, request, pk=None):
|
||||
"""
|
||||
获取当前用户对工单可执行的操作及接单状态。
|
||||
|
||||
前端应使用该接口决定是否展示处理按钮,避免自行解释 participant
|
||||
后与后端实际处理权限不一致。原 transitions 接口保留用于兼容。
|
||||
"""
|
||||
ticket = self.get_object()
|
||||
permission_result = WfService.ticket_handle_permission_check(
|
||||
ticket, request.user
|
||||
)
|
||||
transitions = []
|
||||
if permission_result.get('permission', False):
|
||||
transition_queryset = WfService.get_ticket_transitions(
|
||||
ticket
|
||||
).select_related('source_state', 'destination_state')
|
||||
transitions = TransitionSerializer(
|
||||
instance=transition_queryset, many=True
|
||||
).data
|
||||
return Response({
|
||||
'permission': permission_result.get('permission', False),
|
||||
'need_accept': permission_result.get('need_accept', False),
|
||||
'message': permission_result.get('msg', ''),
|
||||
'in_add_node': ticket.in_add_node,
|
||||
'transitions': transitions,
|
||||
})
|
||||
|
||||
@action(methods=['post'], detail=True, perms_map={'post': '*'})
|
||||
def accpet(self, request, pk=None):
|
||||
"""
|
||||
|
|
|
|||
10
changelog.md
10
changelog.md
|
|
@ -1,3 +1,13 @@
|
|||
## 3.1.2026072713
|
||||
|
||||
- fix: 问题修复
|
||||
- unify workflow action permissions [caoqianming]
|
||||
- other: 其他变更
|
||||
- docs: record Codex context migration plan [caoqianming]
|
||||
- docs: migrate project memory for Codex [caoqianming]
|
||||
- docs: add factory release skill [caoqianming]
|
||||
- docs: add Codex project instructions [caoqianming]
|
||||
- docs: design Claude to Codex context migration [caoqianming]
|
||||
## 3.1.2026072316
|
||||
|
||||
- feat: 新增功能
|
||||
|
|
|
|||
|
|
@ -0,0 +1,217 @@
|
|||
# Claude to Codex Project Context Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Add a project-level Codex entry point, release skill, and sanitized memory set while leaving `.claude` unchanged.
|
||||
|
||||
**Architecture:** `AGENTS.md` contains short, always-on rules. `.agents/skills/release/SKILL.md` contains the opt-in backend release workflow. `.codex/memory/` contains detailed project knowledge linked from a single index so Codex can load it only when relevant.
|
||||
|
||||
**Tech Stack:** Markdown, Codex `AGENTS.md`, Codex project skills
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Add the always-on Codex project instructions
|
||||
|
||||
**Files:**
|
||||
- Create: `AGENTS.md`
|
||||
|
||||
- [x] **Step 1: Create the instruction entry point**
|
||||
|
||||
Add concise sections covering:
|
||||
|
||||
- Repository shape: Django backend here and Vue frontend at `../ehs_web`.
|
||||
- Frontend route/menu behavior: routes are delivered by the backend; do not add new views to `src/config/route.js`.
|
||||
- Python execution: use `D:\projects\factory\.venv\Scripts\python.exe`.
|
||||
- Ignored scripts: never force-add `scripts/*.py` without explicit instruction.
|
||||
- Release policy: never bump or release unless explicitly requested; then use `.agents/skills/release/SKILL.md`.
|
||||
- Production data policy: read-only queries only when relevant, credentials from ignored local configuration, and no secrets in docs or commands.
|
||||
- Pointers to `.codex/memory/MEMORY.md` for detailed context.
|
||||
|
||||
- [x] **Step 2: Verify the entry point**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
rg -n "ehs_web|route.js|.venv|scripts/\\*\\.py|release|只读|memory" AGENTS.md
|
||||
```
|
||||
|
||||
Expected: every rule category appears at least once.
|
||||
|
||||
- [x] **Step 3: Commit**
|
||||
|
||||
```powershell
|
||||
git add -- AGENTS.md
|
||||
git commit -m "docs: add Codex project instructions"
|
||||
```
|
||||
|
||||
### Task 2: Add the opt-in backend release skill
|
||||
|
||||
**Files:**
|
||||
- Create: `.agents/skills/release/SKILL.md`
|
||||
|
||||
- [x] **Step 1: Create the skill**
|
||||
|
||||
Add valid skill frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: factory-release
|
||||
description: Use only when the user explicitly asks to release the factory backend, bump its version, or run the release workflow.
|
||||
---
|
||||
```
|
||||
|
||||
The body must require this exact order:
|
||||
|
||||
1. Confirm the user explicitly requested a backend release.
|
||||
2. Check the working tree and prevent unrelated files from entering the release commit.
|
||||
3. Run `bash update_changelog.sh` and use its emitted version.
|
||||
4. Update `server/settings.py` `SYS_VERSION`.
|
||||
5. Inspect the top of `changelog.md`.
|
||||
6. Stage only `changelog.md` and `server/settings.py`.
|
||||
7. Commit as `release: <VER>` without Claude-specific attribution.
|
||||
8. Create tag `<VER>`, push the branch, then push the tag.
|
||||
9. Report version, changelog categories, commit hash, tag, and push results.
|
||||
|
||||
The skill must state that frontend `ehs_web` releases use a separate workflow documented in `.codex/memory/reference_ehs_web_release.md`.
|
||||
|
||||
- [x] **Step 2: Verify the skill**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
rg -n "explicitly|update_changelog|SYS_VERSION|changelog.md|git tag|git push|ehs_web|Co-Authored-By" .agents/skills/release/SKILL.md
|
||||
```
|
||||
|
||||
Expected: all required release steps appear and `Co-Authored-By` does not appear.
|
||||
|
||||
- [x] **Step 3: Commit**
|
||||
|
||||
```powershell
|
||||
git add -- .agents/skills/release/SKILL.md
|
||||
git commit -m "docs: add factory release skill"
|
||||
```
|
||||
|
||||
### Task 3: Add the sanitized Codex project memory
|
||||
|
||||
**Files:**
|
||||
- Create: `.codex/memory/MEMORY.md`
|
||||
- Create: `.codex/memory/feedback_routing.md`
|
||||
- Create: `.codex/memory/feedback_scripts_gitignore.md`
|
||||
- Create: `.codex/memory/feedback_version_bump.md`
|
||||
- Create: `.codex/memory/project_frontend_ehs_web.md`
|
||||
- Create: `.codex/memory/project_gx_db_access.md`
|
||||
- Create: `.codex/memory/project_material_ofrom_merge_bug.md`
|
||||
- Create: `.codex/memory/reference_ehs_web_release.md`
|
||||
- Create: `.codex/memory/reference_python_venv.md`
|
||||
- Create: `.codex/memory/reference_wrapper_apps.md`
|
||||
|
||||
- [x] **Step 1: Create the memory index**
|
||||
|
||||
Create one relative Markdown link for each of the nine detailed memory files. Each link must summarize when the file is relevant.
|
||||
|
||||
- [x] **Step 2: Migrate stable feedback and references**
|
||||
|
||||
Preserve the operational meaning of:
|
||||
|
||||
- Backend-delivered frontend routes.
|
||||
- The intentional `scripts/*.py` ignore rule.
|
||||
- Explicit-only release/version bumps.
|
||||
- The project virtual environment.
|
||||
- The independent frontend release workflow.
|
||||
- The two wrapper applications.
|
||||
|
||||
Remove Claude session IDs, Claude metadata, wiki-link syntax, and Claude-specific tool names.
|
||||
|
||||
- [x] **Step 3: Migrate project background and historical diagnosis**
|
||||
|
||||
Preserve:
|
||||
|
||||
- Backend/frontend coupling and statistics page conventions.
|
||||
- Read-only production-data verification policy.
|
||||
- The `material_ofrom` historical diagnosis, affected code locations, known evidence, and next investigation point.
|
||||
|
||||
Replace all database credentials with instructions to read connection parameters from ignored local configuration. Do not include usernames, passwords, `PGPASSWORD`, or ready-to-run production connection commands.
|
||||
|
||||
- [x] **Step 4: Verify index targets**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
$missing = @()
|
||||
Get-Content .codex/memory/MEMORY.md |
|
||||
Select-String -AllMatches '\]\(([^)]+\.md)\)' |
|
||||
ForEach-Object { $_.Matches } |
|
||||
ForEach-Object {
|
||||
$target = Join-Path '.codex/memory' $_.Groups[1].Value
|
||||
if (-not (Test-Path -LiteralPath $target)) { $missing += $target }
|
||||
}
|
||||
if ($missing.Count -gt 0) { $missing; exit 1 }
|
||||
"All memory links resolve"
|
||||
```
|
||||
|
||||
Expected: `All memory links resolve`.
|
||||
|
||||
- [x] **Step 5: Commit**
|
||||
|
||||
```powershell
|
||||
git add -- .codex/memory
|
||||
git commit -m "docs: migrate project memory for Codex"
|
||||
```
|
||||
|
||||
### Task 4: Validate migration safety and coverage
|
||||
|
||||
**Files:**
|
||||
- Inspect: `AGENTS.md`
|
||||
- Inspect: `.agents/skills/release/SKILL.md`
|
||||
- Inspect: `.codex/memory/*.md`
|
||||
- Inspect unchanged: `.claude/settings.local.json`
|
||||
- Inspect unchanged: `.claude/commands/release.md`
|
||||
|
||||
- [x] **Step 1: Scan for prohibited Claude artifacts and secrets**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
rg -n -i "originSessionId|scratchpad|PGPASSWORD|Co-Authored-By: Claude|password\s*=|postgresql://" AGENTS.md .agents/skills .codex/memory
|
||||
```
|
||||
|
||||
Expected: no matches.
|
||||
|
||||
- [x] **Step 2: Check topic coverage**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
Get-ChildItem .codex/memory -File | Sort-Object Name | Select-Object -ExpandProperty Name
|
||||
```
|
||||
|
||||
Expected: `MEMORY.md` plus all nine detailed memory files are listed.
|
||||
|
||||
- [x] **Step 3: Confirm Claude files are untouched**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
git status --short -- .claude
|
||||
git diff -- .claude
|
||||
```
|
||||
|
||||
Expected: no output.
|
||||
|
||||
- [x] **Step 4: Check formatting and scoped changes**
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
git diff --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Expected: no whitespace errors; only pre-existing user files and this migration's plan file remain uncommitted.
|
||||
|
||||
- [x] **Step 5: Commit the implementation plan**
|
||||
|
||||
```powershell
|
||||
git add -- docs/superpowers/plans/2026-07-27-claude-to-codex-project-context.md
|
||||
git commit -m "docs: record Codex context migration plan"
|
||||
```
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
# Claude 项目上下文迁移到 Codex:设计说明
|
||||
|
||||
## 目标
|
||||
|
||||
在不删除或修改现有 `.claude` 配置的前提下,把 `factory` 项目中仍有效的 Claude 项目知识迁移成 Codex 可稳定使用的项目级上下文。
|
||||
|
||||
迁移后的配置应做到:
|
||||
|
||||
- Codex 每次进入仓库时都能读取关键项目约束。
|
||||
- 较长的背景资料和历史排障记录不会挤占常规任务上下文。
|
||||
- 发版流程只在用户明确要求时启用。
|
||||
- 不复制数据库口令等敏感信息。
|
||||
- Claude 与 Codex 可以继续并行使用。
|
||||
|
||||
## 现状
|
||||
|
||||
项目内现有 Claude 配置:
|
||||
|
||||
- `.claude/settings.local.json`:Claude 工具授权历史,包含大量机器相关命令及明文数据库连接信息。
|
||||
- `.claude/commands/release.md`:后端发版命令。
|
||||
- Claude 用户目录中的项目 memory:包含前后端关系、动态路由、Python 虚拟环境、生产库只读查询约束、脚本忽略规则、发版约束、套壳 App 背景及一次历史缺陷排查。
|
||||
|
||||
项目当前没有根目录 `CLAUDE.md`、`AGENTS.md` 或项目级 Codex memory。
|
||||
|
||||
## 采用方案
|
||||
|
||||
采用分层兼容结构:
|
||||
|
||||
1. 根目录 `AGENTS.md`
|
||||
- 放置每次工作都应遵守的稳定规则。
|
||||
- 内容保持简短,避免把一次性历史排障细节注入所有任务。
|
||||
- 指向更详细的 memory 和按需 skill。
|
||||
|
||||
2. `.agents/skills/release/SKILL.md`
|
||||
- 把 `.claude/commands/release.md` 转换为 Codex 项目 skill。
|
||||
- 仅在用户明确要求“发版”“release”或“bump 版本”时使用。
|
||||
- 保留版本生成、更新 `SYS_VERSION`、检查 changelog、提交、打 tag 和推送的顺序。
|
||||
- 去掉 Claude 专属的 `Co-Authored-By` 署名。
|
||||
- 保留远端写操作前的工作区检查和失败处理约束。
|
||||
|
||||
3. `.codex/memory/`
|
||||
- `MEMORY.md` 作为主题索引。
|
||||
- 按主题保存项目背景、用户反馈和历史排障资料。
|
||||
- 去除 Claude 的 session ID、Claude 专属元数据和 wiki 链接语法。
|
||||
- 使用普通 Markdown 相对链接,便于人工和 Codex 按需读取。
|
||||
|
||||
4. `.claude/`
|
||||
- 原样保留,不删除、不重写。
|
||||
|
||||
## 内容映射
|
||||
|
||||
必须进入 `AGENTS.md` 的规则:
|
||||
|
||||
- 配套前端位于 `../ehs_web`;后端 API 变化时检查对应前端调用。
|
||||
- `ehs_web` 菜单和路由由后端动态下发,新页面不要修改 `src/config/route.js`。
|
||||
- Django/Python 命令使用项目根目录 `.venv/Scripts/python.exe`。
|
||||
- `scripts/*.py` 是有意忽略的一次性脚本,未经明确要求不得 `git add -f`。
|
||||
- 不自动提升版本或发版,只有用户明确要求时才执行 release skill。
|
||||
- 生产数据库只允许只读查询;任何写操作需要用户另行明确授权。
|
||||
- 不在项目文档、skill 或命令中保存数据库口令。
|
||||
|
||||
保存在 `.codex/memory/` 的资料:
|
||||
|
||||
- 前后端工程关系与统计页面惯例。
|
||||
- 生产数据库只读验证方法,但连接参数只指向本地忽略配置,不记录凭据。
|
||||
- 前端独立发版流程。
|
||||
- 两个 WebView 套壳 App 的位置与交互约定。
|
||||
- `material_ofrom` 合批历史缺陷的排查结论和后续接续点。
|
||||
- 上述关键反馈规则的详细原因。
|
||||
|
||||
不迁移的内容:
|
||||
|
||||
- `.claude/settings.local.json` 中的 Claude 权限语法。
|
||||
- 临时 scratchpad 路径、历史会话 ID、一次性命令白名单。
|
||||
- 数据库用户名、密码及可直接复用的带密码命令。
|
||||
|
||||
## 安全与错误处理
|
||||
|
||||
- 新文件中扫描常见密码片段和 `PGPASSWORD`,确认没有凭据泄漏。
|
||||
- 不读取或修改被 `.gitignore` 排除的本地数据库配置。
|
||||
- 不连接生产数据库验证迁移,因为本任务只迁移文档和工作约束。
|
||||
- 不删除 `.claude`,迁移失败时现有 Claude 工作流不受影响。
|
||||
- 不执行 release skill;仅验证其结构与引用路径。
|
||||
|
||||
## 验证
|
||||
|
||||
完成迁移后执行:
|
||||
|
||||
1. 检查 `AGENTS.md`、`.agents/skills/release/SKILL.md` 和 `.codex/memory/*.md` 均存在。
|
||||
2. 检查 `AGENTS.md` 中的索引链接均能解析到实际文件。
|
||||
3. 搜索新文件中的密码、`PGPASSWORD`、Claude session ID 和临时 scratchpad 路径。
|
||||
4. 对照原 memory 索引,确认所有仍有效主题均已覆盖。
|
||||
5. 检查 Git diff,确认 `.claude` 没有变化,且没有混入用户现有未跟踪文件。
|
||||
|
||||
## 完成标准
|
||||
|
||||
- Codex 项目级入口、按需发版 skill 和 memory 索引全部建立。
|
||||
- 原 Claude 配置保持不变。
|
||||
- 原有 9 个 memory 主题均被迁移或被更高层规则覆盖。
|
||||
- 新配置不含明文凭据或 Claude 专属运行痕迹。
|
||||
- 验证命令通过,Git diff 只包含本次迁移相关文件。
|
||||
|
|
@ -35,7 +35,7 @@ sys.path.insert(0, os.path.join(BASE_DIR, 'apps'))
|
|||
ALLOWED_HOSTS = ['*']
|
||||
|
||||
SYS_NAME = '星途工厂综合管理系统'
|
||||
SYS_VERSION = '3.1.2026072316'
|
||||
SYS_VERSION = '3.1.2026072713'
|
||||
X_FRAME_OPTIONS = 'SAMEORIGIN'
|
||||
|
||||
# Application definition
|
||||
|
|
|
|||
Loading…
Reference in New Issue