refactor: 本仓升为唯一源（原 sap-cli 源码仓归档）
方向反转：此前 SKILL.md 是「模板渲染产物」、sap-cli 是源；现 sap-cli 归档， sap-cli-skill 承接开发与分发，SKILL.md 回归手工维护的正本。 迁移（来自 sap-cli，共 104 文件）： - tests/ 692 例测试（15 个文件的内联 sys.path 改指 assets/） - openspec/ SDD 规格与归档变更（42 文件） - docs/ 开发文档与 ADT 原理（含 dev/CLAUDE.md、AGENTS.md） - .claude/ rules 副本 + settings.json（供 Claude Code） - .github/ .hermes/ .pre-commit-config.yaml .editorconfig CLAUDE.md - scripts/ 保持仅 setup.py（pack_skill.py 已随旧仓归档，不迁） 修复（迁移暴露的真实缺陷）： - assets/pyproject.toml 的 build-backend 写作 `setuptools.backends._legacy:_Backend`， 该模块在 setuptools 中不存在 → `pip install -e` 从来装不上。改为 build_meta。 实测：临时 venv 安装成功，sap-cli --help 正常列出 31 个命令 - pyproject readme 指向不存在的 assets/README.md（editable 安装会失败）→ 改内联文本 - pyproject urls 改指 sap-cli-skill 机制调整： - .github/workflows/ci.yml 适配 assets/ 布局；顶部注明该工作流仅 GitHub 执行， 本仓在 Gitee 不会自动跑 - pre-commit 增本地测试门禁（Gitee 上真正生效的那道） - .gitignore 合并旧仓完整规则（保留 log/ 下 md 知识库入库，只忽略运行日志） - 大文件上限 100KB→1MB（架构图 512KB） 守卫测试 tests/unit/test_repo_guards.py（10 → 18 例）： - SKILL.md 须记录 parser 全部 CLI 命令 / 铁律 1-5 须为真实小节标题 / 示例不得违反铁律 5 - references/ 规则齐备；.claude/rules 与 references 必须一致（实测抓到一次真实漂移） - VERSION == sapcli.__version__ == README 版本 - 仓内不得再出现 pack_skill.py / skill-src（防废弃流程回潮） 698 tests OK；editable 安装与 CLI 入口经临时 venv 实测通过。 docs/RELEASING.md 重写为单源开发流程。
This commit is contained in:
吴让宇
@@ -0,0 +1,4 @@
|
||||
schema: spec-driven
|
||||
change: base-batch
|
||||
status: archived
|
||||
archived_at: "2026-06-09"
|
||||
@@ -0,0 +1,27 @@
|
||||
# Proposal: 批量操作与项目管理
|
||||
|
||||
## Why
|
||||
|
||||
单对象 CRUD 无法满足实际项目中的批量化需求。SAP 项目通常包含数十甚至上百个相互依赖的开发对象，需要批量初始化、状态跟踪、依赖排序和批量同步的能力。同时，传输请求管理是 SAP 开发工作流中不可或缺的一环。
|
||||
|
||||
## What Changes
|
||||
|
||||
- 项目初始化：创建约定目录结构（reports/、classes/、functions/ 等）和 manifest.json
|
||||
- 目录扫描：自动识别 .abap 文件，按约定目录映射对象类型
|
||||
- 清单管理：manifest.json 跟踪对象状态、同步结果和依赖关系
|
||||
- 依赖排序：基于 Kahn 算法进行拓扑排序，确保正确的执行顺序
|
||||
- 批量同步：sync --all 模式，支持 --dry-run 和 --fail-fast
|
||||
- 状态刷新：批量检查 SAP 系统中的对象状态
|
||||
- 传输请求基础管理：list、create、select
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `batch-ops`: 项目级批量操作（初始化、清单管理、扫描、排序、批量同步、状态刷新）
|
||||
|
||||
## Impact
|
||||
|
||||
- 引入 manifest.json 作为项目状态跟踪机制
|
||||
- 建立约定目录结构（reports/、classes/、interfaces/、functions/ 等 10 个目录）
|
||||
- sync 命令新增 --all、--dry-run、--fail-fast 参数
|
||||
- 为后续 P0/P1 扩展（list、whereused、transport 高级管理等）奠定基础
|
||||
@@ -0,0 +1,89 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Project Initialization
|
||||
|
||||
系统 SHALL 初始化一个 ABAP 项目目录结构。
|
||||
|
||||
#### Scenario: Init new project
|
||||
- **WHEN** 用户执行 init 命令并指定项目路径
|
||||
- **THEN** 系统创建标准目录结构（reports/、classes/、functions/ 等）和空的 manifest.json
|
||||
|
||||
### Requirement: Manifest Management
|
||||
|
||||
系统 SHALL 管理项目清单文件，记录所有开发对象的状态。
|
||||
|
||||
#### Scenario: Manifest tracks objects
|
||||
- **WHEN** 对象被创建、同步或删除后
|
||||
- **THEN** 清单文件自动更新对象的状态、最后同步时间和同步结果
|
||||
|
||||
#### Scenario: Query pending objects
|
||||
- **WHEN** 清单中存在未成功同步的对象
|
||||
- **THEN** 系统能够识别并列出这些待处理对象
|
||||
|
||||
#### Scenario: Query up-to-date objects
|
||||
- **WHEN** 清单中存在已激活且同步成功的对象
|
||||
- **THEN** 系统能够过滤出这些就绪对象
|
||||
|
||||
### Requirement: Directory Scanning
|
||||
|
||||
系统 SHALL 扫描本地项目目录，自动识别 ABAP 开发对象文件。
|
||||
|
||||
#### Scenario: Scan standard directories
|
||||
- **WHEN** 项目目录包含约定命名的子目录及其中的 .abap 文件
|
||||
- **THEN** 系统识别每个文件对应的对象名称、类型和路径
|
||||
|
||||
#### Scenario: Function directory structure
|
||||
- **WHEN** 扫描 functions/ 目录
|
||||
- **THEN** 子目录名解析为函数组名，文件名解析为函数模块名
|
||||
|
||||
#### Scenario: Skip hidden files
|
||||
- **WHEN** 目录中存在以 . 开头的文件
|
||||
- **THEN** 系统跳过这些隐藏文件
|
||||
|
||||
### Requirement: Dependency Sorting
|
||||
|
||||
系统 SHALL 根据对象间依赖关系确定正确的执行顺序。
|
||||
|
||||
#### Scenario: Sort by dependency
|
||||
- **WHEN** 对象之间存在依赖关系
|
||||
- **THEN** 被依赖的对象排在前面（如接口在类之前）
|
||||
|
||||
#### Scenario: Same priority tie-breaker
|
||||
- **WHEN** 多个对象无依赖关系
|
||||
- **THEN** 按照类型优先级排序（interface 最高，report 最低）
|
||||
|
||||
#### Scenario: Detect cyclic dependency
|
||||
- **WHEN** 对象间存在循环依赖
|
||||
- **THEN** 系统报告循环依赖错误并显示循环链
|
||||
|
||||
#### Scenario: Ignore external dependencies
|
||||
- **WHEN** 对象依赖了不在当前项目中的外部对象
|
||||
- **THEN** 系统忽略该外部依赖，不报错
|
||||
|
||||
### Requirement: Batch Sync
|
||||
|
||||
系统 SHALL 支持项目级批量同步操作。
|
||||
|
||||
#### Scenario: Sync all objects
|
||||
- **WHEN** 用户执行 sync --all 命令
|
||||
- **THEN** 系统扫描项目、按依赖排序、逐个同步所有对象
|
||||
|
||||
#### Scenario: Dry run mode
|
||||
- **WHEN** 用户执行 sync --all --dry-run
|
||||
- **THEN** 系统仅显示将要同步的对象列表，不实际执行
|
||||
|
||||
#### Scenario: Fail fast mode
|
||||
- **WHEN** 用户执行 sync --all --fail-fast
|
||||
- **THEN** 任一对象同步失败时立即停止
|
||||
|
||||
#### Scenario: Sequential progress
|
||||
- **WHEN** 批量同步进行中
|
||||
- **THEN** 系统逐一显示每个对象的同步进度和结果
|
||||
|
||||
### Requirement: Status Refresh
|
||||
|
||||
系统 SHALL 刷新项目清单中所有对象在 SAP 系统中的状态。
|
||||
|
||||
#### Scenario: Refresh object status
|
||||
- **WHEN** 用户执行 refresh 命令
|
||||
- **THEN** 系统查询每个对象在 SAP 中的最新状态并更新清单
|
||||
@@ -0,0 +1,47 @@
|
||||
## 1. Project Initialization
|
||||
|
||||
- [x] 1.1 Create standard directory structure (reports/, classes/, interfaces/, functions/, domains/, dataelements/, tables/, structures/, tabletypes/)
|
||||
- [x] 1.2 Generate empty manifest.json with version and timestamp
|
||||
- [x] 1.3 Support --path for custom project directory
|
||||
|
||||
## 2. Manifest Management
|
||||
|
||||
- [x] 2.1 Define Manifest and ManifestEntry data classes
|
||||
- [x] 2.2 Implement JSON serialization/deserialization (to_dict/from_dict)
|
||||
- [x] 2.3 Implement load/save/upsert/remove/get operations
|
||||
- [x] 2.4 Track system_status (active/inactive/not_exists)
|
||||
- [x] 2.5 Track last_sync_result (success/failed/pending/skipped)
|
||||
- [x] 2.6 Implement pending_objects() and active_up_to_date_objects() queries
|
||||
|
||||
## 3. Directory Scanning
|
||||
|
||||
- [x] 3.1 Map directory names to object types (DIRECTORY_TYPE_MAP)
|
||||
- [x] 3.2 Parse .abap files into ScannedObject entries
|
||||
- [x] 3.3 Handle functions/ subdirectory as group/module naming
|
||||
- [x] 3.4 Skip hidden files (dot-prefixed)
|
||||
|
||||
## 4. Dependency Sorting
|
||||
|
||||
- [x] 4.1 Implement Kahn's algorithm for topological sort
|
||||
- [x] 4.2 Add TYPE_PRIORITY tie-breaker (interface:50, class:60, function:70, report:80, others:90)
|
||||
- [x] 4.3 Detect cyclic dependencies and raise CyclicDependencyError
|
||||
- [x] 4.4 Ignore external dependencies not in current manifest
|
||||
|
||||
## 5. Batch Sync
|
||||
|
||||
- [x] 5.1 Implement sync --all mode with scan → sort → sequential sync pipeline
|
||||
- [x] 5.2 Add --dry-run flag for preview-only mode
|
||||
- [x] 5.3 Add --fail-fast flag for stop-on-first-error mode
|
||||
- [x] 5.4 Update manifest after each sync attempt
|
||||
- [x] 5.5 Validate --all mode excludes --name and --type
|
||||
|
||||
## 6. Status Refresh
|
||||
|
||||
- [x] 6.1 Query SAP system for each object's current status
|
||||
- [x] 6.2 Update manifest with latest status information
|
||||
|
||||
## 7. Transport Request (Basic)
|
||||
|
||||
- [x] 7.1 Support --corr_nr in sync and create for transport binding
|
||||
- [x] 7.2 Auto-detect object's bound transport request on lock
|
||||
- [x] 7.3 Interactive transport request selection when needed
|
||||
Reference in New Issue
Block a user