Teach planner-scope the owner issue-claim handoff
Check instruction packages / check (push) Successful in 3s
Check instruction packages / check (pull_request) Successful in 3s

This commit is contained in:
admin committed 2026-10-12 09:26:21 -04:00
1 parent ea94dc877e
commit 09f70fd203
4 files changed
+7 -5

No files matched your search

+3 -1
View File
@@ -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.