docs: remove deleted project docs skill requirement

This commit is contained in:
inman
2026-09-09 17:23:56 +08:00
parent 515b545b32
commit bb115a3382
13 changed files with 114 additions and 59 deletions

View File

@@ -15,7 +15,7 @@
- 实际范围、约束、结果、验证、后续项和 durable 结论已记录到当前任务文件。
- 所有相关源码、契约、文档、测试和生成物保持同步;未知或未授权项明确保留为阻断或待办。
- `maintain-project-docs` 的所有权、漂移和完成门禁通过。
- 仓库内的 worktree 安全检查、相关测试和项目文档一致性检查通过。
## Quality Checks
@@ -24,9 +24,8 @@
- `node --run test:control-plane`
- `node --run test:legacy`
- `node --run build`
- 按已加载的 `maintain-project-docs` Skill 运行 `check_project_docs.py` 与当前任务的 `check_doc_drift.py`。
- 涉及 Skill、DOCX 或 Chrome 扩展时,追加各自官方校验、渲染或包/源码逐文件比对。
## Last Reviewed
2026-09-07
2026-09-08

View File

@@ -1,30 +1,41 @@
# Concurrent Task Gate
# Concurrent Worktree Check
Complete this gate before the Planning Gate.
Complete this repository-local check before the Planning Gate. It does not require an external Skill, `task_context.py`, or a separate ownership registry.
## Commands
Run from the intended repository worktree:
```bash
git status --short
git branch --show-current
git rev-parse --show-toplevel
git worktree list --porcelain
git rev-parse HEAD
```
## Invariants
- One active task owns one worktree.
- One worktree carries edits for only one active task at a time.
- Concurrent tasks use different branches and worktrees.
- Never stash, reset, move, delete, or adopt unknown work automatically.
- Feature tasks write only their own task record and uniquely named supporting records.
- Keep the active task record present until ownership is released.
- Treat `start`, `touch`, `complete`, and `release` as serialized registry transactions; lock timeout or malformed registry state blocks the gate.
- Keep an active task record for repository-changing work.
- Treat task records as collaboration context, not locks. Git worktree identity and visible status are the authoritative local safety inputs.
- Feature-task write boundaries in this gate supersede legacy instructions to update shared or canonical project documents.
## Required Output
- Task ID:
- Mode: Feature | Integration
- Branch:
- Worktree:
- Base commit:
- Ownership result: Claimed | Resumed | Isolated | Blocked
- Other active local tasks:
- Existing changes in this worktree:
- Other local worktrees relevant to this scope:
- Overlap result: Clear | Isolated | Blocked
## Block Conditions
- The worktree belongs to another active task and isolation did not succeed.
- An unowned worktree contains staged, unstaged, or untracked changes.
- Existing changes overlap the intended edit and cannot be safely preserved or attributed.
- The intended branch or worktree is ambiguous, or isolation from a conflicting task did not succeed.
- No reliable committed base was selected for a new worktree.
- The runtime cannot keep later Git and file operations rooted in the isolated worktree.

View File

@@ -2,14 +2,15 @@
Before planning, confirm:
- I know the task ID, mode, branch, worktree, base commit, and ownership result.
- I read the active task record and know its scope.
- I know the current branch, absolute worktree, base commit, Git status, and task scope.
- For repository-changing work, I read or created the active task record and know its scope.
- I know what this project is and what it is not.
- I treat current-state as the last integrated snapshot rather than live concurrent state.
- I checked active decisions and the architecture overview.
- I identified task-specific docs that need deeper reading.
- I inspected other local task records through `task_context.py status --json`.
- I inspected `git worktree list --porcelain` and any available peer task records relevant to this scope.
- I assessed code overlap separately from semantic or decision conflict.
- I reported missing peer records as unknown coordination state.
- I can name unknown, stale, or conflicting information.
- I know which updates remain task-scoped and which require Integration Gate.
- I did not rely on an external project-document Skill or task registry.

View File

@@ -4,9 +4,9 @@ Use this gate to promote completed task facts into canonical project memory.
## Requirements
- Run in an exclusively owned integration worktree.
- Hold the repository integration lock.
- For a single completed Feature, create the Integration worktree from that Feature commit so its task-owned records are already inside the Integration task's recorded base. Verify the target default branch is an ancestor or reconcile it explicitly before canonical edits; starting from the older default branch and then introducing another task's record will correctly fail the drift gate.
- Run in an isolated integration worktree when concurrent edits may overlap. A user-requested direct governance update may run in the current worktree only after the repository-local worktree check confirms existing changes are known and non-overlapping.
- Do not require or emulate an external integration lock; use Git worktree isolation, visible status, and explicit conflict checks.
- For a single completed Feature, create the Integration worktree from that Feature commit so its task-owned records are already present. Verify the target default branch is an ancestor or reconcile it explicitly before canonical edits.
- Verify the task commits being integrated are present.
- Review source task records, task-prefixed supporting records, promotion candidates, and semantic conflicts in read-only mode.
- Write integration notes only to the integration task's own task record or `{task_id}__<slug>.md` supporting records.

View File

@@ -1,6 +1,6 @@
# Memory Index
Use this as the high-density entry point after the Concurrent Task Gate establishes task identity and worktree ownership.
Use this as the high-density entry point after the repository-local Concurrent Worktree Check establishes the current branch, worktree, status, and task scope.
## Startup Set

View File

@@ -1,12 +1,12 @@
# Planning Gate
A coding agent must complete this gate after the Concurrent Task Gate and before writing an implementation plan.
A coding agent must complete this gate after the repository-local Concurrent Worktree Check and before writing an implementation plan.
## Peer Scope Check
Run `task_context.py status --json`. For each other owner, read only the peer task record at `Path(owner.worktree) / owner.task_record`. Use its `Scope`, `Intent And Constraints`, and `Promotion Candidates` sections to assess overlap.
Use `git worktree list --porcelain` to identify other local worktrees. When an available peer task record or committed branch diff is relevant, use its scope and promotion candidates to assess overlap.
Do not inspect or modify arbitrary uncommitted files in another task's worktree. Report a missing or unreadable peer record as unknown coordination state; do not silently treat it as no overlap. Code-path overlap alone is a warning. Block when semantic decisions conflict or unresolved overlap could change the plan.
Do not inspect or modify arbitrary uncommitted files in another task's worktree. A missing peer task record is not itself a blocker, but unresolved overlap that could change the plan is. Code-path overlap alone is a warning. Block when semantic decisions conflict or overlapping unknown changes cannot be preserved safely.
## Required Output
@@ -14,12 +14,13 @@ Do not inspect or modify arbitrary uncommitted files in another task's worktree.
## Project Context Loaded
Task context:
- Task ID:
- Mode:
- Task record, if any:
- Mode, if applicable:
- Branch:
- Worktree:
- Base commit:
- Other active local tasks:
- Existing changes:
- Other relevant local worktrees:
- Overlap or semantic-conflict assessment:
Read:
@@ -43,8 +44,8 @@ Gate result:
The gate passes only when:
- task identity and worktree ownership are resolved
- the active task record exists and matches the owner task ID
- current branch, worktree, base commit, status, and task scope are resolved
- the active task record exists for repository-changing work and matches the current scope
- required documents were read
- task-relevant decisions were checked
- relevant evidence, reflection, and commitment indexes were checked when applicable
@@ -56,8 +57,8 @@ The gate passes only when:
Block planning when:
- worktree ownership is unresolved
- an unowned worktree is dirty and has not been explicitly adopted by a human
- the intended branch or worktree is unresolved
- existing overlapping changes cannot be attributed or preserved safely
- required worktree isolation failed or later operations cannot remain rooted there
- required documents are missing or a concurrency upgrade is incomplete
- current integrated state conflicts with the user request

View File

@@ -1,7 +1,7 @@
# Read Before Coding
Before editing code, verify that the implementation plan passed both the Concurrent Task Gate and Planning Gate. Confirm the task ID, branch, worktree, owner, and active task record still match.
Before editing code, verify that the implementation plan passed both the repository-local worktree check and Planning Gate. Confirm the branch, absolute worktree, visible Git status, and current task scope still match; when a task record is being maintained, confirm it also matches.
If the plan is stale, ownership changed, or new peer scope affects the plan, return to `read-before-planning.md`. Keep every later file and Git operation rooted in the owned worktree.
If the plan is stale, the worktree changed, or new peer scope affects the plan, return to `read-before-planning.md`. Keep every later file and Git operation rooted in the checked worktree.
Read the source files directly related to the target modules. Record feature progress, discovered constraints, verification, and promotion candidates in `.project-docs/30-worklog/tasks/{task_id}.md`; leave canonical project memory to Integration Gate.

View File

@@ -2,13 +2,13 @@
Before writing any coding plan, follow this order:
1. Run the Concurrent Task Gate.
1. Run the repository-local Concurrent Worktree Check in `concurrent-task-gate.md`.
2. Read `.project-docs/05-agent-entry/memory-index.md`.
3. Read the active task record at `.project-docs/30-worklog/tasks/{task_id}.md`.
3. Read the active task record, or create one for repository-changing work before planning.
4. Read `.project-docs/00-brief/project-positioning.md`.
5. Read `.project-docs/30-worklog/current-state.md` as the integrated snapshot.
6. Read `.project-docs/10-decisions/decision-index.md` and `.project-docs/20-architecture/system-overview.md`.
7. Inspect other locally active task scopes.
7. Inspect other locally active worktrees and any available task records for scope overlap.
Then read additional files when relevant:
@@ -21,4 +21,4 @@ Then read additional files when relevant:
- Follow-up, loop, timed check, or restart-point task: `.project-docs/80-commitments/commitments.md`
- Suspicious integrated context: `.project-docs/90-maintenance/stale-items.md`
Treat shared files as the last integrated snapshot, not as live state from concurrent feature tasks. Do not write a plan until both the Concurrent Task Gate and Planning Gate pass.
Treat shared files as the last integrated snapshot, not as live state from concurrent feature tasks. Do not write a plan until both the repository-local worktree check and Planning Gate pass. No external Skill or task registry is required.

View File

@@ -0,0 +1,48 @@
# Task: Remove the deleted project-document Skill requirement
## Identity
- Task ID: 20260908-remove-maintain-project-docs-requirement-6d8a31f2
- Mode: Integration
- Branch: main
- Worktree: /Users/inmanx/Documents/lwltAPI
- Base commit: 515b545b32fcbb30311b56c5b90a36f3d3834d95
- Owner: codex
- Status: Completed
## Scope
- Remove repository requirements for the deleted `maintain-project-docs` Skill and its `task_context.py` or Skill-owned validation commands.
- Keep `.project-docs/` as repository-local project memory and replace external ownership mechanics with self-contained Git worktree checks.
## Intent And Constraints
- Preserve the user's pre-existing untracked task record and all unrelated worktree state.
- Do not rewrite historical task records that accurately describe the workflow used at that time.
- Do not change product behavior, release artifacts, schemas, mappings, or runtime code.
## Outcome
- Removed every active startup, ownership, validation, and completion requirement tied to the deleted `maintain-project-docs` Skill, `task_context.py`, or Skill-owned validation scripts.
- Replaced the external ownership/lock workflow with repository-local Git branch, worktree, status, base-commit, and overlap checks.
- Kept `.project-docs/` as the canonical project-memory location and preserved its task-record and Integration review boundaries.
- Renamed the repository-hygiene test so it describes the project-memory invariant without naming the deleted Skill.
- Removed the two exact `.DS_Store` residue files reported by repository hygiene checks; no unrelated source or task record was changed.
## Verification
- `git diff --check`: passed before the final task-record update.
- `node --run check:repo`: passed, 10/10.
- `node --run check`: passed.
- `node --run test:control-plane`: passed.
- `node --run test:legacy`: passed, 273/273.
- `node --run build`: passed.
- Active-reference scan confirmed remaining old command names occur only in historical task/reflection records or in explicit statements that they are not required.
## Follow-ups
- None recorded.
## Promotion Candidates
- None recorded; this task directly updates the repository-wide governance requested by the user.

View File

@@ -12,7 +12,7 @@ Feature tasks must not update current state, task history, shared indexes, accep
## Integration Mode Writes
Integration mode alone may reconcile promotion candidates into current state, shared indexes, accepted ADRs, architecture, domain rules, and shared aggregations. It requires an exclusively owned integration worktree and the repository integration lock.
Integration mode alone may reconcile promotion candidates into current state, shared indexes, accepted ADRs, architecture, domain rules, and shared aggregations. Use an isolated integration worktree whenever concurrent edits may overlap; a user-requested direct governance update may use the current worktree after the repository-local worktree check confirms existing changes are known and non-overlapping. No external Skill or integration-lock service is required.
Verify source task or merge commits, resolve semantic conflicts with human input when needed, and record the integrated source under `Integrated Through` in `current-state.md`. Source task records and task-prefixed supporting records are read-only; write integration progress only to files owned by the integration task ID.

View File

@@ -1,21 +1,23 @@
# LTJT 项目文件治理规则
本文件约束所有后续维护会话。用户指令优先;在没有新的明确指令时,必须遵守以下位置、所有权、同步和归档规则。
本文件约束所有后续维护会话。用户指令优先;在没有新的明确指令时,必须遵守以下位置、协作、同步和归档规则。
## 开始工作前
1. 运行 `git status --short`,保留所有既有未提交改动;禁止 `git reset --hard`、`git clean` 或批量回退。
2. 加载 `maintain-project-docs` Skill,先运行其 Concurrent Task Gate。任何代码或项目文档编辑前,`task_context.py start` 必须成功,且 `status --json` 中的 task ID、mode、绝对 worktree、branch 与当前任务完全一致。
3. 所有权门禁通过后,按 `.project-docs/05-agent-entry/read-before-planning.md` 的顺序加载当前任务和 canonical 项目记忆;Feature 与 Integration 写入边界以该 Skill 和 `.project-docs/90-maintenance/doc-update-policy.md` 为准。
2. 运行 `git branch --show-current`、`git rev-parse --show-toplevel` 和 `git worktree list --porcelain`,按 `.project-docs/05-agent-entry/concurrent-task-gate.md` 完成仓库内自包含的 worktree 安全检查。
3. 按 `.project-docs/05-agent-entry/read-before-planning.md` 的顺序加载当前任务和 canonical 项目记忆;Feature 与 Integration 写入边界以 `.project-docs/90-maintenance/doc-update-policy.md` 为准。
4. 通过 `agent设计规范/business-adaptation-registry.md` 定位业务,再读取对应业务页、Skill、Schema、mapping 和实现代码。
5. `archive/` 只供追溯,不能反向覆盖当前业务规则;若历史文件与活动源码冲突,以活动源码及当前契约为准。
仓库不依赖外部项目文档 Skill。已删除的 `maintain-project-docs`、`task_context.py` 或其专属检查脚本不得作为开始、编辑、验证或完成任务的前置条件。
## 并发与子智能体
- 原则上不创建子智能体;确有必要时必须先取得用户明确同意。
- 一个活动任务只拥有一个 worktree;不得在已被其他任务占用或归属不明的 dirty worktree 中继续。
- 不得用 Markdown 或口头约定模拟任务所有权;只能使用 `maintain-project-docs` 自带的 `task_context.py`。
- 未知改动不得自动 stash、reset、移动、删除或认领;采用 `--adopt-existing` 必须有用户对已知改动的明确接管授权。
- 一个 worktree 同一时间只承载一个活动任务的编辑;不得在已被其他任务占用或归属不明的 dirty worktree 中继续。
- `.project-docs/` 的任务记录用于持久上下文和交接,不充当进程锁或外部所有权注册表;并发判断以当前 Git worktree、branch、status 和可见任务范围为准。
- 未知改动不得自动 stash、reset、移动、删除或认领;若与当前目标重叠且无法安全绕开,必须先询问用户。
## 根目录边界
@@ -35,7 +37,7 @@
| 位置 | 唯一职责 | 禁止内容 |
|---|---|---|
| `.project-docs/` | 任务作用域记录、canonical 项目记忆、证据索引、反思、承诺和文档维护状态 | 运行日志、秘密、业务附件、绕过所有权门禁的共享进度 |
| `.project-docs/` | 任务作用域记录、canonical 项目记忆、证据索引、反思、承诺和文档维护状态 | 运行日志、秘密、业务附件、把任务记录当作并发锁的共享进度 |
| `agent设计规范/` | Agent Prompt、五个 Skill、业务模板、业务入口与稳定测试夹具的可编辑源 | 发布包、运行日志、历史版本副本 |
| `schemas/` | 当前解析态、执行态和 ERP 表单 Schema | 历史 Schema、运行结果 |
| `mappings/` | 当前 ERP 字段与生命周期 mapping | 探针输出、旧版本副本 |
@@ -51,13 +53,13 @@
| `quarantine/` | 无法安全解析的外部输入隔离边界 | 当前源码或已信任 fixture |
| `archive/` | 日期化、只读、可恢复的历史实现、证据、规划和发布物 | 当前入口或需要运行时读取的文件 |
## Maintain Project Docs
## 项目记忆维护
- `.project-docs/30-worklog/tasks/<task_id>.md` 是任务局部范围、约束、结果、验证、后续项和 Promotion Candidates 的唯一记录。
- Feature 模式只写当前 task ID 所属记录和允许的 task-prefixed supporting records;不得更新 `current-state.md`、共享索引、accepted ADR、canonical 架构、业务规则或共享聚合。
- Integration 模式必须独占 worktree 和集成锁,才能把已接受事实写入 canonical 项目记忆;冲突的产品行为、架构方向或真相源必须由用户决定。
- Integration 模式必须使用无冲突的独立 worktree,或在用户明确要求直接更新当前分支时确认既有改动均已知且不重叠,才能把已接受事实写入 canonical 项目记忆;冲突的产品行为、架构方向或真相源必须由用户决定。
- `current-state.md` 是上次集成快照,不代表其他并行任务的实时状态;其他任务只通过其 task record 做只读范围评估。
- 仓库变更任务完成前必须更新任务记录、运行 `check_doc_drift.py --task-id <task_id>`,再用 `task_context.py complete` 标记 `ready_for_integration`。
- 仓库变更任务完成前必须更新当前任务记录并执行本仓库已有、与改动相关的验证;不要求外部完成命令或状态注册。
- 历史 Planning with Files 只供追溯;不得从归档复制回活动项目记忆。
## 单一源与同步矩阵
@@ -79,14 +81,7 @@
## 验证
项目文档或仓库文件调整后,先按已加载的 `maintain-project-docs` Skill 运行:
```text
scripts/check_project_docs.py
scripts/check_doc_drift.py --task-id <task_id>
```
再至少运行:
项目文档或仓库文件调整后,至少运行仓库内已有的以下检查:
```bash
node --run check:repo

View File

@@ -5,7 +5,7 @@
## 新会话入口
1. 先读 [项目文件治理规则](AGENTS.md)。
2. 加载 `maintain-project-docs` Skill,通过 Concurrent Task Gate 取得当前 worktree 所有权。
2. 按 [并发 worktree 检查](.project-docs/05-agent-entry/concurrent-task-gate.md) 核对当前 branch、worktree 和既有改动;该流程不依赖外部 Skill 或任务注册脚本。
3. 按 [项目记忆入口](.project-docs/05-agent-entry/read-before-planning.md) 加载当前任务、集成状态、决策和架构。
4. 通过 [业务适配登记表](agent设计规范/business-adaptation-registry.md) 定位业务入口、Skill、Schema、mapping 和实现。
5. 发布边界看 [生命周期发布门槛](agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md),当前制品看 [发布清单](dist/release-manifest.json)。
@@ -49,7 +49,7 @@ AI Agent/Skill 与确定性解析器都只负责业务语义、字段抽取和
| 目录 | 用途 |
|---|---|
| `.project-docs/` | worktree 所有权门禁、任务作用域记录和经 Integration Gate 更新的 canonical 项目记忆 |
| `.project-docs/` | worktree 协作检查、任务作用域记录和经 Integration Gate 更新的 canonical 项目记忆 |
| `agent设计规范/` | Agent Prompt、五个 Skill、业务模板、业务入口和稳定夹具 |
| `schemas/`、`mappings/` | 当前解析/执行契约与 ERP 映射 |
| `chrome-extension/` | 已登录 ERP 页面内的浏览器适配器源码 |

View File

@@ -117,7 +117,7 @@ test('root contains only governed long-lived entries', async () => {
}
});
test('maintain-project-docs is the sole active project memory', async () => {
test('project docs are the sole active project memory', async () => {
const projectDocs = path.join(ROOT, '.project-docs');
const required = [
'00-brief/project-positioning.md',