Teach planner-scope the owner issue-claim handoff
This commit is contained in:
1 parent
ea94dc877e
commit
09f70fd203
4 files changed
+7
-5
No files matched your search
@@ -3,7 +3,7 @@ name: planner-scope
|
||||
description: Check assigned issue scope, neighboring work, and verification before drafting a Plan.
|
||||
metadata:
|
||||
relayview-display-name: Planner scope
|
||||
relayview-version: 0.2.0
|
||||
relayview-version: 0.3.0
|
||||
---
|
||||
|
||||
# Planner scope
|
||||
@@ -13,3 +13,5 @@ When drafting the assigned Plan, identify the requested behavior, its boundary,
|
||||
If the owner supplies an admitted work-item identity, use the assigned read tools to inspect it. Preserve source attribution; an issue description is a request, not evidence that its proposed behavior exists. Where tracker access is unavailable, state the missing context instead of guessing a work-item identity.
|
||||
|
||||
Write the Plan through the owner's assigned planning interface. The Plan is ready when each requested outcome has an implementation boundary and a checkable success or recovery observation. Owner-controlled workflow stages and checks determine execution authority.
|
||||
|
||||
For a linked Gitea issue, the default claim is the owner's transition from `status/ready-for-agent` to `status/in-progress` after it proves that the exact Plan reached the Implementer. Finalize the Plan through the assigned interface, then use owner-reported handoff and issue-claim outcomes when explaining progress to the Human. An accepted Plan alone does not establish that claim. The operator may disable or replace the status transition through owner policy; follow the effective policy recorded for the task.
|
||||
Reference in new issue
Block a user