コンテンツにスキップ
個人開発者の収益化プレイブック

PR handoff / review テンプレート

このページは、記入用テンプレートを誤ってサイトのメタデータとして解釈しないよう、原文をコードとして表示しています。

原本をダウンロード

---
schema: codex-delivery/pr@1
document_id: "PR-<<required: repository-number or stable ID>>"
change_id: "CHG-<<required: YYYYMMDD-slug>>"
risk_tier: "<<required: R0 | R1 | R2 | R3>>"
document_status: draft
decision_state: UNKNOWN
owner: "<<required: author/owner>>"
evidence_as_of: "<<required: ISO 8601>>"
commit_sha: "<<required: full exact Git object ID reviewed>>"
supersedes: N/A — update by append/revision
refs:
  - TASK-<<required>>
---


# PR handoff and review: <<required: outcome>>


## Immutable review scope


- Repository / base ref and SHA: `<<required>>`
- Head ref and full exact Git object ID: `<<required>>`
- Source tree/diff hash: `<<required>>`
- Candidate schema/config/flag/model/prompt/tool/policy/runtime-authority manifest hash: `<<required or N/A with reason>>`
- Evidence manifest root ID/hash: `<<required: authoritative EVID run manifest>>`
- Draft approved-deploy manifest digest: `<<required for release-bound changes, otherwise N/A with reason>>`
- Handoff generated at/by: `<<required>>`
- Working tree state/untracked files: `<<required>>`
- Handoff state: `draft | ready | stale`


Review binding tuple: `{change_id, base SHA, head SHA, source tree/diff hash, schema/config/tool-policy/runtime-authority manifest hash, evidence manifest root hash, review criteria version}`. Hash and record the tuple: `<<required>>`.


Any reviewed head, tree, config, schema, flag, model, prompt, tool/policy, intended IaC/runtime identity/IAM/DB role/RLS/grants/credential scope/egress, evidence manifest, or review-criteria change makes prior evidence and approval stale unless a new review round records a narrowly proven unaffected subset. Never edit an old approval to point at a new tuple.


## Why and what changed


- Customer/operational outcome: `<<required>>`
- Before: `<<required>>`
- After: `<<required>>`
- Why now/source evidence: `<<required>>`
- Files/components changed: `<<required>>`
- Intentionally unchanged/non-goals: `<<required>>`
- Explanation in the author's own words: `<<required: behavior, state, failure, not a generated file list>>`


## Linked decisions and evidence


| Type | ID/path | Version/fingerprint | Why relevant |
|---|---|---|---|
| Task | TASK-<<required>> | <<required>> | <<required>> |
| ADR | <<required or N/A with reason>> | <<required>> | <<required>> |
| Threat | <<required or N/A with reason>> | <<required>> | <<required>> |
| Eval | <<required or N/A with reason>> | <<required>> | <<required>> |
| Release | <<required or N/A until approved>> | <<required>> | <<required>> |


## Acceptance trace


| AC ID | Implementation location | Evidence ID | Exact command/case | Result | Current for head? |
|---|---|---|---|---|---:|
| AC-01 | <<required>> | EVID-<<required>> | <<required>> | PASS/FAIL/UNKNOWN | yes/no |


Every required `AC-*` needs positive evidence or an explicit blocker. A reviewer should be able to reproduce the claim from this table.


## Verification snapshot


| Evidence ID / manifest hash | Claim/AC | CWD/environment | Exact command/runner | Started/completed | Exit | Passed/failed/skipped/flaky/unknown | Raw artifact/run ID/hash | Current for review tuple? | Limitation/expiry |
|---|---|---|---|---|---:|---|---|---:|---|
| EVID-01 / <<required>> | <<required>> | <<required>> | <<required>> | <<required>> | <<required>> | <<required>> | <<required>> | yes/no | <<required>> |


For R0/R1 a hash of this complete, immutable table plus its raw artifacts may be the run manifest. For separate or multi-run EVALs, reference the authoritative manifest and do not retype PASS counts. Disclose commands not run and why. “CI green” without run ID, workflow/ref, and applicable scope is insufficient.


## Risk delta


| Surface | Changed? | Evidence or reason | Reviewer focus |
|---|---:|---|---|
| Auth/tenant/permission | yes/no/unknown | <<required>> | <<required>> |
| Data/schema/migration/retention | yes/no/unknown | <<required>> | <<required>> |
| Billing/money/tax | yes/no/unknown | <<required>> | <<required>> |
| API/event/backward compatibility | yes/no/unknown | <<required>> | <<required>> |
| Privacy/secret/logging | yes/no/unknown | <<required>> | <<required>> |
| Dependency/build/supply chain | yes/no/unknown | <<required>> | <<required>> |
| Runtime identity/IAM/DB role-RLS/credential scope/egress | yes/no/unknown | <<required>> | <<required>> |
| AI quality/tool authority/cost loop | yes/no/unknown | <<required>> | <<required>> |
| Performance/capacity/observability | yes/no/unknown | <<required>> | <<required>> |
| Release/rollback/support | yes/no/unknown | <<required>> | <<required>> |


## Data, migration, and compatibility


- Schema/migration IDs and hashes: `<<required or N/A with reason>>`
- Forward/backward compatibility window: `<<required>>`
- Backfill/reconciliation result: `<<required or N/A with reason>>`
- API/event/client compatibility: `<<required or N/A with reason>>`
- Irreversible effects: `<<required or N/A with reason>>`


## UI and behavior evidence


- Preview/manual environment: `<<required or N/A>>`
- Screenshots/video/artifact: `<<required or N/A>>`
- Loading/empty/error/permission states: `<<required or N/A>>`
- Keyboard/screen reader/responsive/performance checks: `<<required or N/A>>`


Do not include secrets or unredacted customer data in review artifacts.


## Release and rollback handoff


- Deploy/release/exposure sequence: `<<required>>`
- Canary/cohort/feature flag: `<<required or N/A with reason>>`
- Stop signals: `<<required>>`
- Rollback classes and owner: `<<required>>`
- Last-known-good fingerprint: `<<required>>`
- Post-release observation time: `<<required>>`


## Known limitations and unknowns


| ID | Statement | Risk | Owner | Due | Required before ship? | Evidence to close |
|---|---|---|---|---|---:|---|
| PR-UNK-01 | <<required>> | <<required>> | <<required>> | <<required>> | yes/no | <<required>> |


## Reviewer record


Append one immutable row per round. A new head/config/evidence tuple never overwrites an earlier approval.


| Round/event ID | Reviewer / type | Reviewed binding-tuple hash and exact head | Evidence manifest hash | Criteria/instruction version | Reviewed at | Outcome | Supersedes/invalidates |
|---|---|---|---|---|---|---|---|
| REVIEW-01 | <<required: human, Codex /review, specialist, etc.>> | <<required>> | <<required>> | <<required>> | <<required>> | changes_requested/approved/blocked/unknown | <<required or N/A>> |


An agent review is an additional reviewer, not independent proof of correctness or production authorization.


## Findings


| Finding ID | Initial severity | Residual severity | Active? | Veto? / waivable? | File:line / evidence | Claim and consequence | Reproduction | Required fix | State | Resolution fingerprint | Acceptance authority/scope/expiry/rationale/reopen | Verified by |
|---|---|---|---:|---|---|---|---|---|---|---|---|---|
| FIND-01 | low/medium/high/critical | low/medium/high/critical/unknown | yes/no | yes/no / yes/no | <<required>> | <<required>> | <<required>> | <<required>> | open/resolved/accepted/reopened | <<required or N/A>> | <<required or N/A>> | <<required>> |


`resolved` requires a resolution fingerprint and verification. A non-waivable veto, active Critical risk, authorization isolation failure, or privileged-untrusted CI path cannot be cleared by `accepted`; remove/narrow the scope and reverify it. An active residual High remains `PAUSE` even if accepted/waivable and must be mitigated or scoped below High before `SHIP`. A formally waivable Low/Medium finding needs named authority, policy basis, exact scope, expiry, rationale, and reopen trigger. Do not erase old findings after a fix.


## Post-merge/build/release binding handoff


| Link | Exact expected/input identity | Exact output when available | Proof ID/hash | State |
|---|---|---|---|---|
| reviewed head → merged/source tree | <<required>> | <<pending until merge>> | <<pending>> | PENDING/PASS/FAIL/UNKNOWN |
| source tree → build run/provenance | <<required>> | <<pending until build>> | <<pending>> | PENDING/PASS/FAIL/UNKNOWN |
| build → artifact digest | <<required>> | <<pending until build>> | <<pending>> | PENDING/PASS/FAIL/UNKNOWN |
| artifact → deployment/runtime/authority receipt | <<required>> | <<pending until deploy>> | <<pending>> | PENDING/PASS/FAIL/UNKNOWN |
| schema/config/flag/model/tool policy/runtime authority | <<required>> | approved deploy manifest | <<pending>> | PENDING/PASS/FAIL/UNKNOWN |


These are explicit future handoff expectations. `PENDING` post-merge/build/deploy links do not block a current exact review tuple from `SHIP for merge`; they do block production release/exposure until RELEASE records positive bindings. A merge commit may differ from the reviewed head only when tree/config equivalence is positively proven in the deploy manifest. The release authority separately approves the deploy manifest and, after receipt verification, the runtime promotion manifest—not “the PR” in the abstract.


## Final PR decision


- Unresolved veto findings: `<<required: count/IDs>>`
- Active residual High/Critical findings: `<<required: count/IDs>>`
- Required evidence missing/stale: `<<required: count/IDs>>`
- Current approved review round / binding tuple: `<<required>>`
- Current pre-merge review tuple incomplete: `yes/no — IDs`
- Post-merge links pending: `<<required: IDs; allowed for merge, blocks release/exposure>>`
- Derived state: `STOP | PAUSE | UNKNOWN | SHIP`
- Decision / actor / time: `<<required>>`
- Merge does not authorize production release: `acknowledged by <<required>>`


Derive the state with `STOP > PAUSE > UNKNOWN > SHIP`; do not manually promote it. Any active residual Critical or non-waivable veto is `STOP`; active residual High or a known fix/approval wait is `PAUSE`; missing/stale severity or current review/evidence tuple is `UNKNOWN`; only the current tuple with all required positive evidence and no active residual High/Critical can be `SHIP` for merge. Future post-merge links remain `PENDING` and are resolved in RELEASE.