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