docs: remove deleted project docs skill requirement
This commit is contained in:
inman committed
1 parent
515b545b32
commit
bb115a3382
13 files changed
+114
-59
No files matched your search
@@ -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
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
+48
@@ -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.
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in new issue
Block a user