Padev

.cursorrules

@@ -0,0 +1,155 @@
+# Waverless 项目规则列表
+
+- 关键概念
+  - 规则
+    即当前文件，需要和记忆保持同步
+  - review
+    项目根目录下的 review.md, 用于描述任务（问题）以及记录设计方案和执行记录
+  - design.canvas
+    提到canvas就是指他，因为目前没有别的canvas
+    项目整体设计图，描述执行流程（数据传递、并行结构），数据结构关系
+  - 流程图 | 流程结构
+    使用细致的图表达并行或顺序结构，条件结构；以及数据流转
+    一个阻塞执行的角色应该强化在块里，如子并行task，rpc caller，rpc handler，任务池
+
+- 修改canvas要求
+  - 每次修改都必须，更新项目下canvas，阅读最新内容
+  - 不可擅自删除内容，除非是目标修改内容，其他内容都得保留
+  - 要结合原本canvas内的关联内容修改
+  - 分离关键执行角色，如rpc caller，rpc handler，任务池，子并行task
+  - 将代码函数名，类型名都反映在关联逻辑的位置
+  - 函数具体逻辑要反映成流程图结构，而不是黏贴代码
+    - 例如函数里会spawn任务，就要分离spawn任务和当前函数的对象（概念），然后用图表现他们的关系
+    - 例如多个task直接会通过channel通信，就要展现数据流向，以及两边怎么处理数据的发送接收（阻塞or 非阻塞）
+    - 示例：
+      pub async fn batch_transfer(unique_id: Vec<u8>,version: u64,target_node: NodeID,data: Arc<DataSource>,view: DataGeneralView,) -> WSResult<()> {
+          let total_size = data.size().await?;
+          let total_blocks = (total_size + DEFAULT_BLOCK_SIZE - 1) / DEFAULT_BLOCK_SIZE;
+          let semaphore = Arc::new(Semaphore::new(32));
+          let mut handles = Vec::new();
+          // 发送所有数据块
+          for block_idx in 0..total_blocks {
+              // 获取信号量许可
+              let permit = semaphore.clone().acquire_owned().await.unwrap();
+              let offset = block_idx as usize * DEFAULT_BLOCK_SIZE;
+              let size = DEFAULT_BLOCK_SIZE.min(total_size - offset);
+              // 读取数据块
+              let block_data = data.read_chunk(offset, size).await?;
+              // 构造请求
+              let request = proto::BatchDataRequest {request_id: Some(proto::BatchRequestId {node_id: target_node as u32,sequence: block_idx as u32,}),block_type: data.block_type() as i32,block_index: block_idx as u32,data: block_data,operation: proto::DataOpeType::Write as i32,unique_id: unique_id.clone(),version,};
+              // 发送请求
+              let view = view.clone();
+              let handle = tokio::spawn(async move {
+                  let _permit = permit; // 持有permit直到任务完成
+                  let resp = view.data_general().rpc_call_batch_data.call(view.p2p(),target_node,request,Some(Duration::from_secs(30)),).await?;  
+                  if !resp.success {return Err(WsDataError::BatchTransferFailed {node: target_node,batch: block_idx as u32,reason: resp.error_message,}.into());}
+                  Ok(())
+              });
+              handles.push(handle);
+          }
+          // 等待所有请求完成
+          for handle in handles {   handle.await??;}
+          Ok(())
+      }
+      对象（表上关键类型名）
+      - 当前函数进程
+      - spawn的进程
+      - Semaphore
+      流程结构
+      - 条件和循环
+      - 多个task并行
+      数据流向
+      - 发送数据转移给子进程
+      - semaphore clone   转移给子进程
+      操作（需要表上关键函数名）
+      - 当前函数进程.预先准备
+      - 当前函数进程.阻塞申请semaphore
+      - 当前函数进程.spawn子进程
+      - 子进程.rpc_call
+      - 子进程释放semaphore
+
+- 更新canvas流程
+  - 更新项目下canvas 以进行编辑
+    使用 python3 scripts/sync_md_files.py from_s3fs,  将从s3fs目录获取最新编辑，将在项目目录下访问到 design.canvas
+  - 更新s3fs canvas以反馈review最新修改
+    使用 python3 scripts/sync_md_files.py to_s3fs,  将项目目录下的design.canvas 更新到s3fs目录
+
+- 提到“我更新了canvas”的情况，执行下python3 scripts/sync_md_files.py from_s3fs
+  这样项目下的 {项目根路径}/design.canvas 才是最新的
+  然后在理解分析新的设计
+
+- 函数返回 result的情况，如果不想处理，只要要log error
+
+- log使用tracing库
+
+- error的结构是一个 WSError，包含子error结构形如 WsXXXErr，父结构实现Error derive，子结构只需要实现debug
+  子结构尽量实现现有分类
+
+- 修改代码原则
+  现在review中迭代代码草稿
+  确认草稿后，在更新到当前项目中
+
+## 1. 任务执行强制等待规则
+- 制定计划后必须等待用户确认：
+  - 即使计划看起来很完善
+  - 即使修改很简单
+  - 即使是修复明显的错误
+  - 没有任何例外情况
+
+- 执行前检查清单：
+  - [ ] 任务是否已标记为 working？
+  - [ ] 修改计划是否已制定？
+  - [ ] 计划是否已经得到用户确认？
+  - [ ] 是否在正确的位置记录了计划？
+
+- 执行顺序强制要求：
+  1. 标记任务状态
+  2. 制定修改计划
+  3. **等待用户确认**
+  4. 得到确认后执行
+  5. 记录执行结果
+  6. 等待用户下一步指示
+
+## 2. 基础工作流规则
+- 开始执行分析任务时：
+  先标记当前任务、或子任务为 (working) 状态，working状态同一时间只应该有一个
+
+- 处理任务时：
+  - 如果review还没有计划，则进行计划
+  - 如有计划：
+    - 未执行过计划：等待用户确认后执行
+    - 已执行过计划：等待用户指示
+
+- 分析完或执行完需要回写review规划或记录时：
+  在对应working处更新内容，不要乱选择更新位置
+
+- 编译相关：
+  - agent自行需要编译或用户指明需要编译时：
+    sudo -E $HOME/.cargo/bin/cargo build 2>&1 | tee compilelog
+  - 需要分析当前问题时，先阅读 compilelog
+
+- 步骤管理：
+  每次执行完一个大步骤（更新计划 或 执行计划）后，等待用户下一步指示
+
+## 3. 设计文件修改规则
+- 修改前的准备：
+  - 必须先查看目标文件的最新内容
+  - 创建两份临时文件拷贝，都带上时间戳：
+    * 一份用于修改
+    * 一份作为备份
+
+- 内容修改原则：
+  - 不得擅自删除或覆盖原有内容
+  - 只能修改确实需要更新的相关内容
+  - 不相关的内容必须保持原样
+  - 如果是对原有内容的覆盖修改，需要明确指出
+
+- 文件管理：
+  - 保持清晰的文件命名规范，包含时间戳
+  - 在修改完成后进行必要的备份确认
+
+## 4. 规则同步原则
+- 规则更新时：
+  - 规则文件(.cursorrules)和记忆(MEMORIES)必须同步更新
+  - 确保两者内容保持一致性
+  - 不允许单独更新其中之一

.gitignore

@@ -1,3 +1,4 @@
 target
 *.zip
-Python-3.10.12
+Python-3.10.12
+test_temp_dir*