workflow: replace non-goals template language
This commit is contained in:
parent
b45d8f1f6e
commit
783cd42638
|
|
@ -10,7 +10,7 @@ yoi を yoi で開発する際の、worktree + coder Pod + 外部 reviewer Pod +
|
|||
|
||||
worktree の機械的作成手順は `$user/worktree-workflow`、ユーザー依頼の Ticket 化は `$user/ticket-intake-workflow`、Ticket の next action 分類は `$user/ticket-orchestrator-routing`、実装前の要件同期・反証 preflight は `$user/ticket-preflight-workflow` に分ける。
|
||||
|
||||
この Workflow は、対象 ticket が implementation-ready であることを前提にする。implementation-ready は full implementation plan ではなく、recorded intent / constraints / acceptance criteria / explicit decisions / escalation conditions に基づいて coder が bounded investigation を進め、reviewer が判断できる状態を指す。設計境界・仕様・authority boundary が未同期の場合は、worktree 作成や coder Pod 起動の前に `ticket-preflight-workflow` を通す。
|
||||
この Workflow は、対象 ticket が implementation-ready であることを前提にする。implementation-ready は full implementation plan ではなく、recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions に基づいて coder が bounded investigation を進め、reviewer が判断できる状態を指す。設計境界・仕様・authority boundary が未同期の場合は、worktree 作成や coder Pod 起動の前に `ticket-preflight-workflow` を通す。
|
||||
|
||||
## 目的
|
||||
|
||||
|
|
@ -60,10 +60,10 @@ reviewer Pod
|
|||
- ticket の背景・意図・制約・受け入れ条件から、実装調査と局所 tactic 選択を coder に委ねても product / API / UX / authority / design-boundary decision を silently 固定しないと判断できる。
|
||||
- worktree 作成と git 書き込み操作について、人間の許可がある。
|
||||
- main workspace の unrelated dirty changes を把握している。
|
||||
- 下位 orchestrator に渡す binding decisions / invariants、implementation latitude、non-goals、escalation conditions を短く書ける。
|
||||
- 下位 orchestrator に渡す binding decisions / invariants、implementation latitude、escalation conditions を短く書ける。
|
||||
- 設計境界・仕様・authority boundary に不確定要素がある場合、`ticket-preflight-workflow` の結果が ticket thread に記録されている。
|
||||
|
||||
product / API / UX / authority / design-boundary 方針が複数自然に導ける場合、protocol / scope / permission / history persistence に触れる場合、ticket 自体の再定義が必要な場合は、実装委譲前に `ticket-preflight-workflow` を通し、必要なら人間へ戻す。実装ファイルの探索、既存コード読解、局所的な構成選択のような bounded implementation uncertainty は、intent / constraints / acceptance criteria / escalation conditions が明確なら coder に委ねてよい。
|
||||
product / API / UX / authority / design-boundary 方針が複数自然に導ける場合、protocol / scope / permission / history persistence に触れる場合、ticket 自体の再定義が必要な場合は、実装委譲前に `ticket-preflight-workflow` を通し、必要なら人間へ戻す。実装ファイルの探索、既存コード読解、局所的な構成選択のような bounded implementation uncertainty は、intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions が明確なら coder に委ねてよい。
|
||||
|
||||
## Intent packet
|
||||
|
||||
|
|
@ -86,9 +86,6 @@ Requirements / acceptance criteria:
|
|||
Implementation latitude:
|
||||
- Coder が調査しながら選んでよい local tactic / file-local organization / bounded uncertainty。
|
||||
|
||||
Non-goals / constraints:
|
||||
- 今回やらないこと、触ってはいけない場所。
|
||||
|
||||
Escalate if:
|
||||
- 親へ戻すべき判断条件。特に product / API / UX / authority boundary / explicit design constraint を変える必要が出た場合。
|
||||
|
||||
|
|
@ -99,7 +96,7 @@ Reviewer focus:
|
|||
- reviewer が確認すべき critical risks。
|
||||
```
|
||||
|
||||
reviewer には coder の実装方針ではなく、この intent packet と diff を中心に読ませる。reviewer は recorded intent / constraints / acceptance criteria / explicit decisions に照らして判断し、不記録の preferred tactic を基準にしない。
|
||||
reviewer には coder の実装方針ではなく、この intent packet と diff を中心に読ませる。reviewer は recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / explicit escalation conditions に照らして判断し、不記録の preferred tactic を基準にしない。
|
||||
|
||||
## orchestrator の責務
|
||||
|
||||
|
|
@ -126,7 +123,7 @@ reviewer には coder の実装方針ではなく、この intent packet と dif
|
|||
- main workspace の `TODO.md` / `tickets/` / `docs/report/` / `.yoi` は編集しないこと
|
||||
- child worktree 内の tracked `.yoi` project records は実装対象に必要な branch-local artifacts/dossiers として編集してよいが、`.yoi/memory` や local/runtime/secret-like files は作らないこと
|
||||
- active orchestration progress と最終 review/approval/close は main workspace の責任として残すこと
|
||||
- 範囲外事項
|
||||
- 遵守すべき binding decisions / invariants と escalation conditions
|
||||
- 実行すべき build / test / format
|
||||
- 完了報告項目
|
||||
|
||||
|
|
@ -166,7 +163,7 @@ reviewer には coder の実装方針ではなく、この intent packet と dif
|
|||
- main workspace の管理ファイルを書かない。
|
||||
- child worktree 内の tracked `.yoi` project records は ticket 要件に必要な branch-local artifact/dossier として扱ってよい。
|
||||
- `.yoi/memory`、local/runtime state、logs、locks、secret-like files を child worktree に作らない。
|
||||
- intent / requirements / acceptance criteria / binding decisions / invariants / non-goals / implementation latitude を読んでから実装する。
|
||||
- intent / requirements / acceptance criteria / binding decisions / invariants / implementation latitude / escalation conditions を読んでから実装する。
|
||||
- 実装ファイルの探索、既存コード読解、局所的な tactic 選択は、intent packet の implementation latitude 内で行ってよい。
|
||||
- 指定された build / test / format を実行する。
|
||||
- ticket 要件外または binding decisions/invariants 外の設計変更、依存関係追加、scope / permission / history persistence / prompt context 加工原則に触れる変更が必要なら止めて orchestrator に報告する。
|
||||
|
|
@ -188,7 +185,7 @@ reviewer は coder の subordinate ではない。orchestrator 配下の sibling
|
|||
- 実際のコード変更が概念的に何を変えたかを説明する。
|
||||
- 親や上位 orchestrator が line-by-line diff を読まずに判断できるよう、以下を整理する。
|
||||
- 変更の概念モデル
|
||||
- recorded intent / constraints / acceptance criteria / explicit decisions との対応
|
||||
- recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / explicit escalation conditions との対応
|
||||
- binding decisions / invariants 違反の有無
|
||||
- 旧概念・禁止語彙・不要な互換層の残存
|
||||
- validation の妥当性
|
||||
|
|
|
|||
|
|
@ -38,8 +38,9 @@ Intake は以下を行う。
|
|||
- 必要に応じて関連 docs / code / workflow / history を読む。
|
||||
- 不足している要件を質問する。
|
||||
- Ticket の title / slug / kind / priority / labels を提案する。
|
||||
- background / requirements / acceptance criteria / non-goals / escalation conditions を整理する。
|
||||
- background / requirements / acceptance criteria / escalation conditions を整理する。
|
||||
- binding decisions / invariants と implementation latitude を分けて書く。
|
||||
- 具体的な除外や触れてはいけない境界が binding decision である場合は、generic な除外リストではなく invariant / escalation condition として明記する。
|
||||
- readiness / needs_preflight / risk flags を明示する。
|
||||
- ユーザー合意後に Ticket を作成する。
|
||||
- 既存 Ticket の refinement を求められた場合は、TicketComment で経緯を残す。
|
||||
|
|
@ -103,7 +104,7 @@ Ticket tools が利用できない環境では、勝手に file write で代替
|
|||
- observable な完了条件は何か。
|
||||
- Ticket の種類は何か: feature / bug / cleanup / design / spike / workflow / docs / release / orchestration。
|
||||
- 受け入れ条件は何か。
|
||||
- やらないことは何か。
|
||||
- binding decision として残す具体的な除外・authority boundary はあるか。
|
||||
- 後方互換が必要か。
|
||||
- authority boundary / scope / permission / history / prompt context に触れるか。
|
||||
- validation は何で確認できるか。
|
||||
|
|
@ -117,7 +118,7 @@ Ticket 作成または更新前に、readiness を明示する。
|
|||
|
||||
```text
|
||||
implementation_ready:
|
||||
- 意図・制約・受け入れ条件・non-goals / invariants が明確。
|
||||
- 意図・受け入れ条件・binding decisions / invariants / implementation latitude が明確。
|
||||
- Reviewer が判断できる基準と escalation conditions が明確。
|
||||
- 実装調査や局所的な tactic 選択は残っていてよいが、product / API / UX / authority boundary / explicit design constraint を coder が silently 決める余地はない。
|
||||
- validation が書ける。
|
||||
|
|
@ -178,7 +179,9 @@ Requirements:
|
|||
|
||||
Acceptance criteria:
|
||||
|
||||
Non-goals:
|
||||
Binding decisions / invariants:
|
||||
|
||||
Implementation latitude:
|
||||
|
||||
Escalation conditions:
|
||||
|
||||
|
|
@ -237,8 +240,6 @@ Intake はここで止まる。implementation / worktree / coder / reviewer 起
|
|||
|
||||
## Implementation latitude
|
||||
|
||||
## Non-goals / constraints
|
||||
|
||||
## Readiness
|
||||
|
||||
- readiness: implementation_ready | requirements_sync_needed | spike_needed | blocked | unspecified
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Yoi の multi-agent 運用で、Intake や人間が作成した Ticket を Orche
|
|||
|
||||
Panel Queue / queued notification は、人間が Orchestrator に routing を開始してよいと許可した signal であり、unattended scheduler ではない。implementation side effect に進む場合は、Orchestrator が Ticket と workspace state を再確認し、unblocked と判断してから `queued -> inprogress` を記録する必要がある。
|
||||
|
||||
`ready` は Orchestrator routing に十分な状態であり、実装戦術が事前にすべて固定されている状態ではない。Orchestrator は、recorded intent / constraints / acceptance criteria / explicit decisions / escalation conditions が揃っていれば、bounded implementation uncertainty を残したまま implementation-ready と判断してよい。
|
||||
`ready` は Orchestrator routing に十分な状態であり、実装戦術が事前にすべて固定されている状態ではない。Orchestrator は、recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions が揃っていれば、bounded implementation uncertainty を残したまま implementation-ready と判断してよい。
|
||||
|
||||
## 位置づけ
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ Orchestrator は対象 Ticket を以下のいずれかに分類する。
|
|||
|
||||
- Ticket の目的は見えるが、observable な完了条件が書けない。
|
||||
- ユーザー判断がないと product/API/UX を固定してしまう。
|
||||
- acceptance criteria または non-goals が不足している。
|
||||
- acceptance criteria、binding decisions / invariants、または escalation conditions が不足している。
|
||||
- existing decisions / docs / closed Tickets と矛盾する可能性がある。
|
||||
|
||||
Action:
|
||||
|
|
@ -147,7 +147,7 @@ Action:
|
|||
|
||||
条件:
|
||||
|
||||
- intent / constraints / acceptance criteria が明確。
|
||||
- intent / binding decisions / invariants / implementation latitude / acceptance criteria が明確。
|
||||
- binding decisions / invariants と implementation latitude が区別されている。
|
||||
- reviewer が判断する basis と escalation conditions が明確。
|
||||
- validation が書ける。
|
||||
|
|
@ -174,7 +174,7 @@ Action:
|
|||
Action:
|
||||
|
||||
- reviewer Pod 起動または追加 validation を提案する。
|
||||
- reviewer は recorded intent / constraints / acceptance criteria / explicit decisions に照らして判断する。不記録の好みや Orchestrator の未共有 preferred tactic を基準にしない。
|
||||
- reviewer は recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / explicit escalation conditions に照らして判断する。不記録の好みや Orchestrator の未共有 preferred tactic を基準にしない。
|
||||
- `TicketComment` に review target と確認観点を記録する。
|
||||
- blocker 未解決のまま merge-ready としない。
|
||||
|
||||
|
|
@ -260,7 +260,8 @@ Action:
|
|||
- Background
|
||||
- Requirements
|
||||
- Acceptance criteria
|
||||
- Non-goals / invariants
|
||||
- Binding decisions / invariants
|
||||
- Implementation latitude
|
||||
- Readiness / needs_preflight / risk flags
|
||||
- Escalation conditions
|
||||
- Validation
|
||||
|
|
@ -313,6 +314,7 @@ Intent:
|
|||
|
||||
Binding decisions / invariants:
|
||||
- 人間/Orchestrator/Ticket に記録済みで coder / reviewer が従うべき decision と、壊してはいけない design / authority boundary。
|
||||
- 具体的な除外・触れてはいけない場所が binding decision である場合はここに書く。
|
||||
|
||||
Requirements / acceptance criteria:
|
||||
- 完了時に満たす observable な要件と reviewer が判断できる基準。
|
||||
|
|
@ -320,9 +322,6 @@ Requirements / acceptance criteria:
|
|||
Implementation latitude:
|
||||
- Coder が調査しながら選んでよい local tactic / file-local organization / bounded uncertainty。
|
||||
|
||||
Non-goals / constraints:
|
||||
- 今回やらないこと、触ってはいけない場所。
|
||||
|
||||
Escalate if:
|
||||
- 親/人間に戻す判断条件。特に product / API / UX / authority boundary / explicit design constraint を変える必要が出た場合。
|
||||
|
||||
|
|
@ -333,7 +332,7 @@ Current code map:
|
|||
- 実装対象と触ってはいけない場所。
|
||||
|
||||
Critical risks / reviewer focus:
|
||||
- reviewer にも見てほしい失敗パターン。reviewer は recorded intent / constraints / acceptance criteria / explicit decisions に照らして判断し、不記録の preferred tactic を基準にしない。
|
||||
- reviewer にも見てほしい失敗パターン。reviewer は recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / explicit escalation conditions に照らして判断し、不記録の preferred tactic を基準にしない。
|
||||
```
|
||||
|
||||
IntentPacket が短く書けない場合、`implementation_ready` ではなく `preflight_needed` または `requirements_sync_needed` に戻す。
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ requires: []
|
|||
|
||||
yoi プロジェクトで ticket を実装に渡す前に、要件・前提・設計境界・反証観点を同期するための Workflow。これは **実装前の gate** であり、worktree 作成や coder / reviewer Pod の起動は `multi-agent-workflow` / `worktree-workflow` 側で扱う。
|
||||
|
||||
目的は「ticket があるから実装する」状態を避け、ticket が **実装可能な intent / constraints / acceptance criteria** を持つのか、**調査 ticket** なのか、**人間との仕様同期が必要な未決定 ticket** なのかを明確にすることである。実装 tactic をすべて事前固定する必要はないが、product / API / UX / authority boundary / explicit design constraint を coder が silently 決める余地は残さない。
|
||||
目的は「ticket があるから実装する」状態を避け、ticket が **実装可能な intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions** を持つのか、**調査 ticket** なのか、**人間との仕様同期が必要な未決定 ticket** なのかを明確にすることである。実装 tactic をすべて事前固定する必要はないが、product / API / UX / authority boundary / explicit design constraint を coder が silently 決める余地は残さない。
|
||||
|
||||
## 適用する場面
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ yoi プロジェクトで ticket を実装に渡す前に、要件・前提・
|
|||
|
||||
```text
|
||||
implementation-ready:
|
||||
- intent / constraints / acceptance criteria / reviewer judgment basis が明確。
|
||||
- intent / binding decisions / invariants / implementation latitude / acceptance criteria / reviewer judgment basis が明確。
|
||||
- binding decisions / invariants と implementation latitude が区別されている。
|
||||
- bounded implementation investigation や local tactic 選択は残っていてよい。
|
||||
- product / API / UX / authority boundary / explicit design constraint を coder が silently 決める余地がない。
|
||||
|
|
@ -77,7 +77,7 @@ blocked-needs-human-decision:
|
|||
- 完了時に observable に何が変わるか。
|
||||
- ticket の主語は何か: user-facing behavior / internal architecture / cleanup / investigation。
|
||||
- 用語が既存設計と一致しているか。
|
||||
- 何をやらないか。
|
||||
- binding decision として残す具体的な除外・authority boundary は何か。
|
||||
- 後方互換が必要か、不要な互換層を作ろうとしていないか。
|
||||
- 既存の authority boundary を変えるか。
|
||||
- runtime state / persisted state / config / profile / manifest / session log / pod metadata のどれが authority か。
|
||||
|
|
@ -122,6 +122,7 @@ Intent:
|
|||
|
||||
Binding decisions / invariants:
|
||||
- 人間/Orchestrator/Ticket に記録済みで coder / reviewer が従うべき decision と、壊してはいけない authority boundary / design boundary。
|
||||
- 具体的な除外・触れてはいけない場所が binding decision である場合はここに書く。
|
||||
|
||||
Requirements / acceptance criteria:
|
||||
- observable な完了条件と reviewer が判断できる基準。
|
||||
|
|
@ -129,9 +130,6 @@ Requirements / acceptance criteria:
|
|||
Implementation latitude:
|
||||
- Coder が調査しながら選んでよい local tactic / file-local organization / bounded uncertainty。
|
||||
|
||||
Non-goals / constraints:
|
||||
- 今回やらないこと、触ってはいけない場所。
|
||||
|
||||
Escalate if:
|
||||
- 親/人間に戻す判断条件。特に product / API / UX / authority boundary / explicit design constraint を変える必要が出た場合。
|
||||
|
||||
|
|
@ -142,14 +140,14 @@ Current code map:
|
|||
- 実装対象と触ってはいけない場所。
|
||||
|
||||
Critical risks / reviewer focus:
|
||||
- reviewer にも見てほしい失敗パターン。reviewer は recorded intent / constraints / acceptance criteria / explicit decisions に照らして判断し、不記録の preferred tactic を基準にしない。
|
||||
- reviewer にも見てほしい失敗パターン。reviewer は recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / explicit escalation conditions に照らして判断し、不記録の preferred tactic を基準にしない。
|
||||
```
|
||||
|
||||
この intent packet が短く書けない場合は、実装委譲せず requirements-sync-needed とする。
|
||||
|
||||
## review への引き継ぎ
|
||||
|
||||
preflight で出た critical risks は reviewer Pod にも渡す。reviewer は diff だけでなく、ticket の recorded intent / constraints / acceptance criteria / explicit decisions と preflight の反証観点を読む。reviewer は不記録の preferred tactic ではなく、記録済みの意図・制約・受け入れ条件・binding decisions に対して実装が十分かを判断する。
|
||||
preflight で出た critical risks は reviewer Pod にも渡す。reviewer は diff だけでなく、ticket の recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / explicit escalation conditions と preflight の反証観点を読む。reviewer は不記録の preferred tactic ではなく、記録済みの intent / binding decisions / invariants / implementation latitude / acceptance criteria に対して実装が十分かを判断する。
|
||||
|
||||
reviewer に期待すること:
|
||||
|
||||
|
|
|
|||
|
|
@ -551,7 +551,7 @@ fn append_orchestrator_agent_routing_guidance(out: &mut String) {
|
|||
out.push_str("- Use `worktree-workflow` for the mechanical worktree plan: create `.worktree/<task-name>`, keep tracked `.yoi` project records visible in the child worktree, exclude `.yoi/memory` plus local/runtime/log/lock/secret-like `.yoi` paths, and keep active orchestration progress plus final review/approval/close in the main workspace unless explicitly designed otherwise.\n");
|
||||
out.push_str("- Use `multi-agent-workflow` for the sibling loop: coder and reviewer are siblings under this Orchestrator; coder gets narrow write scope to the child worktree; reviewer is read-only by default.\n");
|
||||
out.push_str("- Give the coder an intent packet that distinguishes binding decisions/invariants, implementation latitude, escalation conditions, child worktree/branch, validation commands, and report expectations; require Bash commands to `cd` into the child worktree, prohibit editing main-workspace `.yoi`/Ticket/workflow/docs records, and prohibit creating generated memory/local/runtime/secret-like files in the child worktree.\n");
|
||||
out.push_str("- Give the reviewer the recorded Ticket intent, constraints, acceptance criteria, explicit decisions, diff/commits, validation evidence, and blocker/non-blocker criteria; reviewer judgment is against recorded requirements and decisions, not unrecorded preferred tactics. Keep branch-local reviewer verdicts in the review report or merge-ready dossier rather than recording them as final main-branch Ticket approval.\n");
|
||||
out.push_str("- Give the reviewer the recorded Ticket intent, binding decisions/invariants, implementation latitude, acceptance criteria, explicit escalation conditions, diff/commits, validation evidence, and blocker/non-blocker criteria; reviewer judgment is against recorded requirements and decisions, not unrecorded preferred tactics. Keep branch-local reviewer verdicts in the review report or merge-ready dossier rather than recording them as final main-branch Ticket approval.\n");
|
||||
out.push_str("- Ticket thread progress may record worktree plan, coder delegated/completed/blocked, reviewer delegated, blocker/fix-loop summaries, and merge-ready dossier pointer; do not merge, close, or record final main approval in this routing/branch-review phase.\n");
|
||||
out.push_str("- Stop at a merge-ready dossier for `orchestrator-merge-completion` containing Ticket id/slug, branch/worktree, commits, intent/invariant check, implementation summary, coder/reviewer Pods, blockers fixed or rejected findings with reasons, validation performed, residual risks, dirty state, and parent/human decision needs if any.\n");
|
||||
|
||||
|
|
@ -569,14 +569,14 @@ fn append_coder_agent_routing_guidance(out: &mut String) {
|
|||
out.push_str("\nCoder worktree routing guidance:\n");
|
||||
out.push_str("- Implement only in the provided child worktree/branch. Use `cd <worktree>` before Bash commands and do not edit main-workspace `.yoi`, Ticket, workflow, docs, or memory records; child-worktree `.yoi` project records may be visible when they are part of the branch.\n");
|
||||
out.push_str("- Do not create `.yoi/memory`, local/runtime state, logs, locks, caches, sockets, or secret-like files in the child worktree.\n");
|
||||
out.push_str("- Treat the intent packet, binding decisions/invariants, constraints/non-goals, implementation latitude, validation expectations, and report expectations as the contract. Investigate and choose local tactics only within the recorded implementation latitude; escalate to Orchestrator rather than expanding scope when design, permission, history, prompt-context, dependency, or Ticket-boundary questions appear.\n");
|
||||
out.push_str("- Treat the intent packet, binding decisions/invariants, implementation latitude, validation expectations, and report expectations as the contract. Investigate and choose local tactics only within the recorded implementation latitude; escalate to Orchestrator rather than expanding scope when design, permission, history, prompt-context, dependency, or Ticket-boundary questions appear.\n");
|
||||
out.push_str("- Report worktree path, branch, commits/status, changed files, implementation summary, validation run, unresolved notes, and whether the branch is ready for external review. Do not merge, push, close Tickets, or delete worktrees.\n");
|
||||
}
|
||||
|
||||
fn append_reviewer_agent_routing_guidance(out: &mut String) {
|
||||
out.push_str("\nReviewer worktree routing guidance:\n");
|
||||
out.push_str("- Review as a sibling of the coder under Orchestrator, read-only by default. Read the Ticket/intent packet, branch diff or commits, and validation evidence before judging. Judge implementation against recorded intent, constraints, acceptance criteria, and explicit decisions, not unrecorded preferred tactics.\n");
|
||||
out.push_str("- Classify findings as blockers, non-blocking follow-ups, or parent-decision items against the recorded intent, constraints, acceptance criteria, binding decisions/invariants, and non-goals; include concrete file/line evidence where useful.\n");
|
||||
out.push_str("- Review as a sibling of the coder under Orchestrator, read-only by default. Read the Ticket/intent packet, branch diff or commits, and validation evidence before judging. Judge implementation against recorded intent, binding decisions/invariants, implementation latitude, acceptance criteria, and explicit escalation conditions, not unrecorded preferred tactics.\n");
|
||||
out.push_str("- Classify findings as blockers, non-blocking follow-ups, or parent-decision items against the recorded intent, binding decisions/invariants, implementation latitude, acceptance criteria, and explicit escalation conditions; include concrete file/line evidence where useful.\n");
|
||||
out.push_str("- Keep the branch-local reviewer verdict in the review report for the Orchestrator merge-ready dossier. Do not record final main-branch Ticket approval, merge, close, push, or instruct the coder directly.\n");
|
||||
}
|
||||
|
||||
|
|
@ -1124,7 +1124,7 @@ workflow = "ticket-review-workflow"
|
|||
assert!(reviewer_text.contains("branch: work/ticket-role-pod-launcher"));
|
||||
assert!(reviewer_text.contains("approve or request changes"));
|
||||
assert!(reviewer_text.contains("read-only by default"));
|
||||
assert!(reviewer_text.contains("recorded intent, constraints, acceptance criteria"));
|
||||
assert!(reviewer_text.contains("recorded intent, binding decisions/invariants"));
|
||||
assert!(reviewer_text.contains("not unrecorded preferred tactics"));
|
||||
assert!(reviewer_text.contains("branch-local reviewer verdict"));
|
||||
assert!(reviewer_text.contains("Do not record final main-branch Ticket approval"));
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ Intake should:
|
|||
|
||||
- clarify user intent;
|
||||
- check duplicate/related Tickets;
|
||||
- draft background, requirements, acceptance criteria, non-goals, readiness, risk flags, and validation;
|
||||
- draft background, requirements, acceptance criteria, binding decisions/invariants, implementation latitude, readiness, risk flags, and validation;
|
||||
- create or update the Ticket only after user agreement.
|
||||
|
||||
Intake should not schedule implementation, spawn coder/reviewer Pods, create worktrees, merge, or close Tickets.
|
||||
|
|
@ -173,7 +173,7 @@ Preflight should resolve or record:
|
|||
|
||||
- requirements and acceptance criteria;
|
||||
- current code map;
|
||||
- invariants and non-goals;
|
||||
- binding decisions/invariants and implementation latitude;
|
||||
- critical risks and failure modes;
|
||||
- implementation-ready vs requirements-sync/spike/blocked classification.
|
||||
|
||||
|
|
@ -187,8 +187,8 @@ The Orchestrator should prepare an `IntentPacket` with:
|
|||
|
||||
- intent;
|
||||
- requirements;
|
||||
- invariants;
|
||||
- non-goals;
|
||||
- binding decisions/invariants;
|
||||
- implementation latitude;
|
||||
- escalation conditions;
|
||||
- validation;
|
||||
- current code map;
|
||||
|
|
@ -316,7 +316,7 @@ A useful Ticket states:
|
|||
- background and motivation;
|
||||
- requirements;
|
||||
- acceptance criteria;
|
||||
- relevant constraints and non-goals;
|
||||
- relevant binding decisions/invariants, implementation latitude, and escalation conditions;
|
||||
- readiness / preflight needs / risk flags when relevant;
|
||||
- implementation reports when work is submitted;
|
||||
- reviews;
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user