diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 2042d12..d0edd71 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -30,6 +30,7 @@ Closes # - [ ] Required stage or final result comment exists. - [ ] Smoke tests were run or reason is documented. - [ ] Primary outcome, smallest acceptance proof, and execution envelope are recorded; supporting work did not become an independent stage, handoff, completion target, or approval gate without crossing an explicit boundary. +- [ ] Blocking review findings, when present, contain sufficient correction contracts; agent-reported addressed findings map to changes and evidence, and reviewer verification remains separate. - [ ] Security and evidence work did not block acceptance or expand scope without a verified High/Critical current-scope risk or an exactly cited mandatory requirement; other items remain non-blocking. - [ ] Mandatory containerization decision was confirmed when relevant, or not applicable. - [ ] Changed Compose configuration was rendered and checked, or reason and risk are documented. diff --git a/AGENTS.md b/AGENTS.md index 3e0d80a..373005e 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -20,6 +20,8 @@ Use GitHub Issues and Pull Requests as the primary workflow system. Report each meaningful Issue with a required stage or final result comment. +For Pull Request review or `changes-requested` work, read `ai/REVIEW_PROTOCOL.md`. A blocking finding must provide a sufficient correction contract, while implementation guidance remains non-binding unless an exact mandatory requirement is cited. An agent-reported `addressed` finding still requires reviewer verification. + Prioritize the stated primary outcome and its smallest acceptance proof. Record the execution envelope before implementation. Keep supporting work subordinate: fix localized, reversible supporting-work failures and perform bounded post-fix verification within the same work item and authorization. Create a stage, handoff, or completion target only when the outcome materially advanced, the acceptance proof completed, a verified blocker is outside the execution envelope, or work is genuinely interrupted or transferred. A supporting-tool failure alone does not require new owner approval; request a decision only when an explicit approval boundary is crossed. After two consecutive supporting-only updates without outcome progress, mark the work `progress-stalled` and replan the shortest path. Security and evidence work MUST NOT block acceptance or expand scope without a verified High or Critical current-scope risk supported by reproducible evidence or a directly applicable authoritative source. A suspected High or Critical risk permits only a short, time-boxed investigation until confirmed. Keep Low, Medium, unrated, and unverified risks non-blocking; preserve the existing security baseline and prioritize the smallest useful end-to-end scenario. An exact acceptance criterion or verified mandatory requirement is an independent blocker only when cited. diff --git a/AGENT_HANDOFF_STANDARD.md b/AGENT_HANDOFF_STANDARD.md index bda861e..1aba887 100644 --- a/AGENT_HANDOFF_STANDARD.md +++ b/AGENT_HANDOFF_STANDARD.md @@ -1,8 +1,8 @@ --- standard: Agent Handoff -version: "1.5" +version: "1.5.1" status: active -updated: 2026-07-26 +updated: 2026-07-27 --- # Agent Handoff Standard @@ -35,6 +35,7 @@ ai/HANDOFF_PROTOCOL.md ai/AGENT_IDENTITY.md ai/WORK_CLAIM_PROTOCOL.md ai/TASK_REPORT_PROTOCOL.md +ai/REVIEW_PROTOCOL.md ai/REFACTORING.md ai/handoffs/INDEX.md .github/ISSUE_TEMPLATE/ @@ -56,11 +57,12 @@ Before meaningful work, read: 6. `ai/AGENT_IDENTITY.md` 7. `ai/WORK_CLAIM_PROTOCOL.md` 8. `ai/TASK_REPORT_PROTOCOL.md` -9. `ai/PROJECT_STATE.md` -10. `ai/DECISIONS.md` -11. `ai/CONTAINERIZATION.md` when Docker or Compose is used, planned, or being discussed -12. related GitHub Issue or Pull Request -13. relevant handoffs through `ai/handoffs/INDEX.md` +9. `ai/REVIEW_PROTOCOL.md` when reviewing a Pull Request, responding to `changes-requested`, or resuming work with open blocking findings +10. `ai/PROJECT_STATE.md` +11. `ai/DECISIONS.md` +12. `ai/CONTAINERIZATION.md` when Docker or Compose is used, planned, or being discussed +13. related GitHub Issue or Pull Request +14. relevant handoffs through `ai/handoffs/INDEX.md` ## Task result reports @@ -72,6 +74,8 @@ Small single-stage Issues must have one final result comment before the work is Use `ai/TASK_REPORT_PROTOCOL.md` for the required comment templates. +When blocking review findings are addressed, use the correction report in `ai/TASK_REPORT_PROTOCOL.md`. + ## Workflow 1. Select or create a GitHub Issue. @@ -234,6 +238,33 @@ A 10–15% share of stage work for security and evidence may be used as a non-bi Reviews, task reports, and handoffs must distinguish verified blocking High or Critical risks, time-boxed investigations of suspected High or Critical risks, follow-up hardening, and owner-accepted risks. +## Actionable review handoff + +A blocking review MUST hand off more than the fact that a defect exists. It must provide a sufficient correction contract so another agent can act without private chat history. + +Each blocking finding must have: + +- a stable finding ID; +- evidence and reproduction, or an exactly cited acceptance criterion or verified mandatory requirement when runtime reproduction is not applicable; +- the violated behavioral, architectural, compatibility, security, or acceptance contract; +- a cause marked `confirmed`, `likely`, or `unknown`; +- the required observable outcome; +- invariants and a scope guard; +- minimum applicable verification and expected evidence; +- observable acceptance criteria. + +Implementation guidance is optional and MUST NOT become a hidden acceptance criterion. An equivalent correction is valid when it achieves the required outcome, preserves the stated invariants, remains inside the execution envelope, and supplies the required evidence. A reviewer must not reject it solely because it differs from the recommended implementation. + +Positive, negative, security, and race tests are selected by applicability, not required mechanically for every finding. Race tests are required only when concurrency, lifecycle ordering, cancellation, retries, cleanup, or shared state is material. + +The full correction contract is mandatory only for findings classified `blocking`. Non-blocking findings and questions may remain concise but must be classified clearly. A security or evidence finding remains subject to the proportionality rule above; this review protocol does not make an otherwise ineligible finding blocking. + +An agent reports each blocking finding as `addressed`, `disputed`, `blocked`, or `not-addressed` and maps it to the change and evidence. `Addressed` is not `verified`: only the reviewer or another authorized maintainer verifies the correction. Finding state normally follows `open -> addressed -> verified`; failed verification reopens it. + +A review finding does not widen the agent's authority or Issue scope. If every safe correction crosses an approval boundary, the agent must state the minimum required expansion and request the applicable owner decision. + +Use `ai/REVIEW_PROTOCOL.md` for the complete templates and lifecycle. + ## Definition of Done - related Issue or PR is linked; @@ -247,6 +278,7 @@ Reviews, task reports, and handoffs must distinguish verified blocking High or C - changes are committed; - smoke tests were run or reason is documented; - PR description is updated; +- blocking review findings have sufficient correction contracts and are verified or otherwise validly dispositioned before merge; - verified blocking High or Critical risks, time-boxed investigations, follow-up hardening, and owner-accepted risks are distinguished; - security and evidence work did not block acceptance or expand scope without a verified High or Critical current-scope risk or an exactly cited mandatory requirement; - handoff exists for meaningful work; diff --git a/CHANGELOG.md b/CHANGELOG.md index 93cc8af..99b1408 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,28 @@ All notable changes to Agent Handoff are documented here. +## 1.5.1 - 2026-07-27 + +### Why + +- Standard 1.5 defined when work and findings may block progress, but it did not define how a reviewer hands a blocking finding back to an implementation agent. A bare defect statement could cause clarification loops, accidental scope expansion, weakened invariants, or treatment of an implementation suggestion as a hidden acceptance criterion. + +### Added + +- `ai/REVIEW_PROTOCOL.md` with blocking, non-blocking, and question classifications. +- A required blocking correction contract with stable finding ID, evidence, violated contract, cause confidence, required outcome, invariants, scope guard, applicable verification, and acceptance criteria. +- Agent Handoff Review Correction Report mapped by finding ID. +- Finding lifecycle `open -> addressed -> verified`, distinct from Pull Request labels. +- Release notes in `docs/releases/v1.5.1.md`. + +### Changed + +- Implementation guidance is explicitly non-binding when an equivalent safe correction satisfies the required outcome, preserves invariants, remains inside the execution envelope, and provides the required evidence. +- Root-cause confidence must be marked `confirmed`, `likely`, or `unknown`. +- Positive, negative, security, and race tests are selected by applicability rather than required mechanically for every finding. +- Agent-reported `addressed` status no longer implies reviewer verification or automatic review-thread resolution. +- GitHub workflow, task reporting, handoff rules, Pull Request checklist, public documentation, and structural checks now cover the correction loop. + ## 1.5 - 2026-07-26 ### Why diff --git a/CITATION.cff b/CITATION.cff index 42ae1e4..ec18344 100644 --- a/CITATION.cff +++ b/CITATION.cff @@ -4,8 +4,8 @@ title: "Agent Handoff: GitHub-native context handoff for AI coding agents" authors: - family-names: "Boyko" given-names: "Artyom" -version: "1.5" -date-released: 2026-07-26 +version: "1.5.1" +date-released: 2026-07-27 url: "https://github.com/artyomboyko/Agent_Handoff" repository-code: "https://github.com/artyomboyko/Agent_Handoff" license: "GPL-3.0-only" @@ -19,6 +19,8 @@ keywords: - "handoff-protocol" - "outcome-oriented-execution" - "bounded-supporting-work" + - "actionable-review-handoff" + - "review-correction" - "proportionate-security" - "docker-compose" - "containerization" diff --git a/FAQ.md b/FAQ.md index 3d47b1e..3d1ecef 100644 --- a/FAQ.md +++ b/FAQ.md @@ -33,3 +33,11 @@ No by default. Use meaningful branch names and link Issues through Work Claim co Test harnesses, smoke wrappers, evidence collectors, CI scaffolding, and similar tools usually exist to enable or prove another outcome. Turning every localized failure into a separate stage, handoff, or approval cycle can advance the process without advancing that outcome. Agent Handoff therefore keeps reversible in-scope repairs and bounded post-fix verification inside the original execution envelope. The envelope records existing authorization and cannot be used by an agent to grant itself broader authority. A new owner decision is still required when the outcome, scope, architecture, accepted baseline, external effects, resource or risk boundary, security baseline, or enforced permission gate changes. + +## What makes a blocking review actionable for an agent? + +A blocking review gives each finding a stable ID and enough evidence, contract, outcome, invariant, scope, verification, and acceptance information for another agent to correct it without private chat history. + +The reviewer may recommend an implementation, but that recommendation is not a hidden acceptance criterion. An equivalent safe correction remains valid when it satisfies the required outcome, preserves invariants, stays inside the execution envelope, and provides the required evidence. + +An agent can report a finding as `addressed`; the reviewer or another authorized maintainer still verifies it before merge. diff --git a/README.md b/README.md index 4c1c4c4..20dc541 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Agent Handoff -[![Standard](https://img.shields.io/badge/standard-1.5-blue)](AGENT_HANDOFF_STANDARD.md) +[![Standard](https://img.shields.io/badge/standard-1.5.1-blue)](AGENT_HANDOFF_STANDARD.md) [![Language](https://img.shields.io/badge/language-English-blue)](docs/en/README.md) [![GitHub native](https://img.shields.io/badge/GitHub-native-black)](ai/GITHUB_WORKFLOW.md) [![AI agent ready](https://img.shields.io/badge/AI%20agent-ready-purple)](ai/AGENT_IDENTITY.md) @@ -65,6 +65,11 @@ Keep supporting work minimum sufficient. Fix localized reversible supporting-wor Do not create a separate stage, handoff, completion target, or owner approval gate for a supporting-tool failure alone. After two consecutive supporting-only updates without outcome progress, mark the work progress-stalled and replan the shortest path. +When requesting changes in a Pull Request, classify findings as blocking, non-blocking, or questions. +Give each blocking finding a stable ID and a sufficient correction contract: evidence or reproduction, violated contract, cause confidence, required outcome, preserved invariants, scope guard, applicable verification, and acceptance criteria. +Treat implementation guidance as non-binding when an equivalent safe correction satisfies the outcome and invariants. +Keep agent-reported addressed status separate from reviewer-verified resolution. + Open a Pull Request and leave a compact handoff. ``` @@ -77,6 +82,7 @@ Open a Pull Request and leave a compact handoff. 5. Humans stay in control of structural and migration decisions. 6. Security and evidence work blocks or expands scope only for verified High or Critical current-scope risk or an exactly cited mandatory requirement. 7. Supporting work stays subordinate to the primary outcome and its smallest acceptance proof. +8. Blocking review findings carry sufficient correction contracts without prescribing one implementation unnecessarily. ## What is included @@ -88,6 +94,7 @@ Open a Pull Request and leave a compact handoff. | Memory map | [ai/README.md](ai/README.md) | | Work claim | [ai/WORK_CLAIM_PROTOCOL.md](ai/WORK_CLAIM_PROTOCOL.md) | | Task reports | [ai/TASK_REPORT_PROTOCOL.md](ai/TASK_REPORT_PROTOCOL.md) | +| Review corrections | [ai/REVIEW_PROTOCOL.md](ai/REVIEW_PROTOCOL.md) | | Agent identity | [ai/AGENT_IDENTITY.md](ai/AGENT_IDENTITY.md) | | Refactoring workflow | [ai/REFACTORING.md](ai/REFACTORING.md) | | Containerization | [ai/CONTAINERIZATION.md](ai/CONTAINERIZATION.md) | @@ -95,7 +102,7 @@ Open a Pull Request and leave a compact handoff. | Issue status | [ISSUE_STATUS.md](ISSUE_STATUS.md) | | FAQ | [FAQ.md](FAQ.md) | | Examples | [examples/](examples/) | -| Release notes | [docs/releases/v1.5.md](docs/releases/v1.5.md) | +| Release notes | [docs/releases/v1.5.1.md](docs/releases/v1.5.1.md) | ## Comparison @@ -109,7 +116,7 @@ Open a Pull Request and leave a compact handoff. ## Natural search terms -Agent Handoff is related to AI coding agents, Codex-like agents, ChatGPT coding workflows, Cursor, Claude Code, LLM agents, project context, agent memory, GitHub workflow, multi-agent development, handoff protocol, pull request workflow, outcome-oriented execution, bounded supporting work, progress-stalled recovery, proportionate security, evidence scope, vertical slices, containerization decisions, Docker Compose organization, and human-agent collaboration. +Agent Handoff is related to AI coding agents, Codex-like agents, ChatGPT coding workflows, Cursor, Claude Code, LLM agents, project context, agent memory, GitHub workflow, multi-agent development, handoff protocol, pull request workflow, actionable review handoff, review correction contract, outcome-oriented execution, bounded supporting work, progress-stalled recovery, proportionate security, evidence scope, vertical slices, containerization decisions, Docker Compose organization, and human-agent collaboration. ## For humans @@ -117,7 +124,7 @@ Use Agent Handoff to see who owns work, what changed, what was tested, what rema ## For agents -Start from `AGENTS.md`, read the required files, claim work in GitHub, record the primary outcome and execution envelope, keep supporting work subordinate, ask for required user decisions, keep security and evidence non-blocking unless a High or Critical current-scope risk is verified, open a Draft PR early, keep `ai/` compact, and leave a handoff only at a legitimate outcome boundary, blocker, interruption, or transfer. +Start from `AGENTS.md`, read the required files, claim work in GitHub, record the primary outcome and execution envelope, keep supporting work subordinate, ask for required user decisions, keep security and evidence non-blocking unless a High or Critical current-scope risk is verified, use `ai/REVIEW_PROTOCOL.md` for blocking review corrections, open a Draft PR early, keep `ai/` compact, and leave a handoff only at a legitimate outcome boundary, blocker, interruption, or transfer. ## Repository visibility diff --git a/ai/DECISIONS.md b/ai/DECISIONS.md index b68f045..f8f6b79 100644 --- a/ai/DECISIONS.md +++ b/ai/DECISIONS.md @@ -2,7 +2,7 @@ type: architecture_record version: 1 status: active -updated: 2026-07-26 +updated: 2026-07-27 project: Agent_Handoff --- @@ -95,6 +95,7 @@ Do not allow the agent to infer approval or automatically apply the recommended - `AGENT_HANDOFF_STANDARD.md` - `ai/CONTAINERIZATION.md` - `ai/HANDOFF_PROTOCOL.md` + - `docs/en/README.md` ## 2026-07-18 — Stable GUI automation over position-dependent tests @@ -214,3 +215,51 @@ A new owner decision remains required for changes to the outcome or acceptance c - `ai/WORK_CLAIM_PROTOCOL.md` - `ai/TASK_REPORT_PROTOCOL.md` - `ai/HANDOFF_PROTOCOL.md` + +## 2026-07-27 — Actionable review handoff without implementation lock-in + +Status: accepted in Standard 1.5.1 + +### Background + +Standard 1.5 defined blocking eligibility, outcome progress, execution envelopes, and approval boundaries, but did not define the reviewer-to-agent correction handoff. A blocking comment could identify a defect without enough reproduction, contract, invariant, verification, or acceptance information for another agent to act independently. + +Requiring only a reviewer-proposed implementation would close the information gap by creating a different problem: it could turn guidance into an undocumented acceptance criterion and reject equally safe solutions. + +### Decision + +Require every blocking finding to carry a stable ID and a sufficient correction contract: evidence or reproduction, violated contract, cause confidence, required outcome, invariants and scope guard, minimum applicable verification, and observable acceptance criteria. + +Mark cause confidence as `confirmed`, `likely`, or `unknown`. Treat implementation guidance as optional and non-binding unless an exact mandatory requirement makes the choice normative. + +Allow equivalent corrections when they satisfy the required outcome, preserve the stated invariants, remain inside the execution envelope, and provide the required evidence. + +Keep finding state distinct from Pull Request state. The implementation agent may mark a finding `addressed`, but only the reviewer or another authorized maintainer marks it `verified`. + +Apply the complete contract only to blocking findings. Keep non-blocking findings and questions concise and explicitly classified. + +### Rejected alternatives + +- Require the full template for every nit, optional suggestion, or question. +- Require every finding to have positive, negative, security, and race tests. +- Treat a reviewer-recommended implementation as the only acceptable correction. +- Let `addressed` automatically resolve a review thread. +- Let a review finding widen the original authorization or Issue scope. +- Add automated semantic scoring of review quality. + +### Consequences + +- Coding agents receive self-contained, verifiable correction tasks without private chat history. +- Root-cause hypotheses are not represented as confirmed facts. +- Architecture and security invariants remain explicit during correction. +- Review cycles map finding IDs to changes, evidence, and independent verification. +- Equivalent safe implementations remain possible. +- The structural checker validates protocol fields but does not judge review semantics. + +### Related + +- Issue: #18 +- Pull Request: #19 +- `AGENT_HANDOFF_STANDARD.md` +- `ai/REVIEW_PROTOCOL.md` +- `ai/TASK_REPORT_PROTOCOL.md` diff --git a/ai/GITHUB_WORKFLOW.md b/ai/GITHUB_WORKFLOW.md index 5082e22..e7b24ff 100644 --- a/ai/GITHUB_WORKFLOW.md +++ b/ai/GITHUB_WORKFLOW.md @@ -2,7 +2,7 @@ type: github_workflow version: 1 status: active -updated: 2026-07-26 +updated: 2026-07-27 project: Agent_Handoff --- @@ -26,6 +26,8 @@ One work item should have one Issue, one scope, one primary outcome, one smalles Closed Issue or merged PR is the normal `done` state. +Finding-level states such as `open`, `addressed`, and `verified` are recorded in review threads or correction reports and are not additional status labels. + ## Branch naming Use meaningful branch names without `/`, Issue numbers, or random identifiers by default. @@ -42,6 +44,22 @@ Small Issues use one final result comment. Use `ai/TASK_REPORT_PROTOCOL.md`. +## Review correction loop + +Use `ai/REVIEW_PROTOCOL.md` for Pull Request review and `changes-requested` work. + +A blocking finding must carry a sufficient correction contract. The implementation agent maps each finding ID to the change and evidence in an Agent Handoff Review Correction Report. + +The agent may report a finding as `addressed`, but only the reviewer or another authorized maintainer marks it `verified`. + +The normal Pull Request transition is: + +```text +in-review -> changes-requested -> in-review -> ready-to-merge +``` + +Return to `in-review` when the correction report and required checks are available. Use `ready-to-merge` only after all blocking findings are verified or otherwise validly dispositioned and required checks pass. + ## Workflow 1. Create or select an Issue. @@ -55,5 +73,7 @@ Use `ai/TASK_REPORT_PROTOCOL.md`. 9. Keep discussion and result reports in Issue or PR. 10. Keep supporting work subordinate and handle localized fixes and bounded post-fix verification inside the current work item. 11. Run checks and smoke tests. -12. Finish only after checks, review, and result report. -13. Add a handoff only at a legitimate outcome boundary, blocker, interruption, or transfer. +12. When review requests changes, address stable blocking finding IDs and write a correction report. +13. Return to review and keep agent-reported `addressed` separate from reviewer-confirmed `verified`. +14. Finish only after checks, review, verified or validly dispositioned blocking findings, and required result reporting. +15. Add a handoff only at a legitimate outcome boundary, blocker, interruption, or transfer. diff --git a/ai/HANDOFF_PROTOCOL.md b/ai/HANDOFF_PROTOCOL.md index 0363bea..a39ec3f 100644 --- a/ai/HANDOFF_PROTOCOL.md +++ b/ai/HANDOFF_PROTOCOL.md @@ -2,7 +2,7 @@ type: handoff_protocol version: 1 status: active -updated: 2026-07-26 +updated: 2026-07-27 project: Agent_Handoff --- @@ -14,6 +14,8 @@ Read the required Agent Handoff files, the related Issue or PR, current branch, Read `ai/CONTAINERIZATION.md` when Docker or Docker Compose is used, planned, present in the repository, or part of the requested work. +Read `ai/REVIEW_PROTOCOL.md` when reviewing a Pull Request, responding to `changes-requested`, or resuming work with open blocking findings. + Choose `agent_name`, `agent_id`, and `run_id` before taking work. ## Work claim @@ -30,6 +32,18 @@ Small Issues use one final result comment before completion. Use `ai/TASK_REPORT_PROTOCOL.md`. +## Actionable review handoff + +A blocking review must provide a stable finding ID, evidence or reproduction, violated contract, cause confidence, required outcome, preserved invariants, scope guard, applicable verification, and observable acceptance criteria. + +Treat implementation guidance as a recommendation unless an exact mandatory requirement makes the implementation choice normative. Equivalent safe corrections remain valid when they satisfy the required outcome, preserve invariants, remain inside the execution envelope, and provide the required evidence. + +After correction, write one compact Agent Handoff Review Correction Report that maps every blocking finding ID to status, change, implementation choice, evidence, preserved invariants, and remaining concern. + +Agent-reported `addressed` does not mean `verified` and does not automatically resolve a review thread. Return the Pull Request to `in-review`; only the reviewer or another authorized maintainer verifies the correction. + +Do not let a review finding widen authority or scope. Stop and request the applicable decision if every safe correction crosses an existing approval boundary. + ## Scope One meaningful work item should have one Issue, one branch, one PR, and one clear scope. @@ -138,6 +152,7 @@ For container changes, also run the applicable Compose rendering, image build, s - Stage and handoff boundaries reflect outcome progress, completed acceptance proof, an out-of-envelope blocker, or genuine interruption or transfer. - `progress-stalled` was handled after two consecutive supporting-only updates without outcome progress. - PR description is updated. +- Blocking review findings have sufficient correction contracts, and each is verified or otherwise validly dispositioned before merge. - Verified blocking High or Critical risks, time-boxed investigations, follow-up hardening, and owner-accepted risks are distinguished. - Security and evidence work did not block acceptance or expand scope without a verified High or Critical current-scope risk or an exactly cited mandatory requirement. - Handoff file is created when needed. diff --git a/ai/PROJECT_STATE.md b/ai/PROJECT_STATE.md index b101207..04b3fd1 100644 --- a/ai/PROJECT_STATE.md +++ b/ai/PROJECT_STATE.md @@ -2,7 +2,7 @@ type: project_state version: 1 status: active -updated: 2026-07-26 +updated: 2026-07-27 project: Agent_Handoff --- @@ -10,7 +10,7 @@ project: Agent_Handoff ## Current phase -Agent Handoff Standard 1.5 is the active standard. +Agent Handoff Standard 1.5.1 is the active standard. The repository is maintained as an English-only canonical version. @@ -23,6 +23,7 @@ The repository is maintained as an English-only canonical version. - Agent identity protocol. - Work claim protocol. - Task report protocol for stage and final result comments. +- Actionable review handoff protocol for blocking correction contracts and reviewer verification. - Refactoring workflow. - FAQ and examples. - GitHub Actions checks workflow. @@ -43,6 +44,9 @@ The repository is maintained as an English-only canonical version. - Outcome-based stage and handoff boundaries. - `progress-stalled` recovery after two consecutive supporting-only updates without outcome progress. - Structural checks for the outcome fields without automated semantic progress scoring. +- Stable review finding IDs with cause confidence, required outcomes, invariants, scope guards, applicable verification, and acceptance criteria. +- Agent correction reports that keep `addressed` distinct from reviewer-confirmed `verified`. +- Implementation freedom for equivalent safe corrections that satisfy the correction contract. ## Main files @@ -54,11 +58,12 @@ The repository is maintained as an English-only canonical version. - `ai/AGENT_IDENTITY.md` - `ai/WORK_CLAIM_PROTOCOL.md` - `ai/TASK_REPORT_PROTOCOL.md` +- `ai/REVIEW_PROTOCOL.md` - `ai/REFACTORING.md` - `ai/CONTAINERIZATION.md` - `.github/pull_request_template.md` - `scripts/check_agent_handoff.py` -- `docs/releases/v1.5.md` +- `docs/releases/v1.5.1.md` ## Active decisions @@ -75,17 +80,20 @@ The repository is maintained as an English-only canonical version. - Supporting-tool failures do not create separate stages, handoffs, completion targets, or approval gates unless an explicit outcome or approval boundary is crossed. - One bounded post-fix verification rerun is permitted after each relevant fix unless the execution envelope is stricter. - Two consecutive supporting-only updates without outcome progress trigger `progress-stalled` and shortest-path replanning. +- Blocking review findings require a sufficient correction contract; non-blocking findings and questions remain lightweight. +- Implementation guidance does not become a hidden acceptance criterion when an equivalent safe correction satisfies the required outcome and invariants. +- Agent-reported `addressed` findings remain open until reviewer or authorized maintainer verification. ## Current publication -- Standard version: `1.5` +- Standard version: `1.5.1` - Status: active -- Publication date: 2026-07-26 -- Issue: #16 -- Pull Request: #17 +- Publication date: 2026-07-27 +- Issue: #18 +- Pull Request: #19 ## Next 1. Keep repository checks and public documentation synchronized with future standard changes. -2. Collect feedback from projects adopting the outcome-oriented execution rule. +2. Collect feedback from projects adopting outcome-oriented execution and actionable review handoffs. 3. Prepare a future version only through a focused Issue, branch, Pull Request, checks, and release handoff. diff --git a/ai/README.md b/ai/README.md index 539e90e..d699b0a 100644 --- a/ai/README.md +++ b/ai/README.md @@ -2,7 +2,7 @@ type: ai_readme version: 1 status: active -updated: 2026-07-18 +updated: 2026-07-27 project: Agent_Handoff --- @@ -21,13 +21,14 @@ It does not replace GitHub Issues, Pull Requests, checks, or Git history. 5. `ai/AGENT_IDENTITY.md` 6. `ai/WORK_CLAIM_PROTOCOL.md` 7. `ai/TASK_REPORT_PROTOCOL.md` -8. `ai/PROJECT_STATE.md` -9. `ai/DECISIONS.md` -10. `ai/CONTAINERIZATION.md` when Docker or Compose is used, planned, present, or being discussed -11. related Issue or PR -12. `ai/REFACTORING.md` when relevant -13. `ai/handoffs/INDEX.md` -14. relevant handoff files only +8. `ai/REVIEW_PROTOCOL.md` when reviewing, responding to `changes-requested`, or resuming a PR with open blocking findings +9. `ai/PROJECT_STATE.md` +10. `ai/DECISIONS.md` +11. `ai/CONTAINERIZATION.md` when Docker or Compose is used, planned, present, or being discussed +12. related Issue or PR +13. `ai/REFACTORING.md` when relevant +14. `ai/handoffs/INDEX.md` +15. relevant handoff files only ## Files @@ -38,6 +39,7 @@ It does not replace GitHub Issues, Pull Requests, checks, or Git history. - `AGENT_IDENTITY.md` — agent identity protocol. - `WORK_CLAIM_PROTOCOL.md` — work claim protocol. - `TASK_REPORT_PROTOCOL.md` — required result comments. +- `REVIEW_PROTOCOL.md` — blocking review correction contracts, agent correction reports, and reviewer verification. - `REFACTORING.md` — refactoring workflow. - `CONTAINERIZATION.md` — user-controlled Docker and Compose layout decisions, supported approaches, migration rules, and checks. - `handoffs/INDEX.md` — handoff index. diff --git a/ai/REVIEW_PROTOCOL.md b/ai/REVIEW_PROTOCOL.md new file mode 100644 index 0000000..a1e6ce6 --- /dev/null +++ b/ai/REVIEW_PROTOCOL.md @@ -0,0 +1,136 @@ +--- +type: review_protocol +version: 1 +status: active +updated: 2026-07-27 +project: Agent_Handoff +--- + +# Actionable Review Handoff Protocol + +This file defines how a reviewer hands correction work to an implementation agent and how the agent returns it for verification. + +GitHub Pull Request reviews and review threads remain the source of work truth. Do not duplicate full discussions in `ai/`. + +## Finding classes + +Every review finding that may affect merge readiness must be classified explicitly: + +- `blocking` - must be corrected, withdrawn, or explicitly accepted by an authorized maintainer before merge; +- `non-blocking` - recommendation or follow-up that does not prevent merge; +- `question` - request for clarification that is not implicitly blocking. + +An ambiguous comment is not a blocking finding until the reviewer marks it as blocking and provides the required correction contract. + +Security and evidence findings remain subject to the proportionality rule in `AGENT_HANDOFF_STANDARD.md`. This protocol defines how an eligible blocker is handed off; it does not make an ineligible finding blocking. + +When the platform supports pending reviews, the reviewer SHOULD batch findings and submit the completed review before an agent begins correction work. + +## Blocking correction contract + +A blocking review MUST provide enough information for another agent to correct and verify the defect without relying on private chat history. + +Each blocking finding must include: + +1. `Finding ID` - a stable identifier unique within the Pull Request, such as `RH-01`; +2. `Evidence and reproduction` - the relevant location, trigger, event order when material, observed result, and expected result; when runtime reproduction is not applicable, cite the exact acceptance criterion or verified mandatory requirement; +3. `Violated contract` - the behavioral, architectural, compatibility, security, or acceptance contract that is not satisfied; +4. `Cause` - `confirmed`, `likely`, or `unknown`, followed by the established cause or bounded hypothesis; +5. `Required outcome` - the observable state that must become true; +6. `Invariants and scope guard` - behavior and controls that must remain true, plus material non-goals or areas that must not be changed; +7. `Verification` - the minimum applicable regression, negative, security, concurrency, or other checks and the evidence expected from them; +8. `Acceptance criteria` - observable conditions for reviewer verification. + +`Implementation guidance` is optional. When present, it should identify a recommended approach and any constraints on acceptable alternatives. + +Do not claim a root cause is confirmed when it is only inferred. Do not require positive, negative, security, and race tests mechanically for every finding. Select the checks that can fail under the identified scenario; race tests are required only when concurrency, lifecycle ordering, cancellation, retries, cleanup, or shared state is relevant. + +One correction contract may cover multiple locations only when they share the same violated contract, required outcome, invariants, and verification. Otherwise use separate finding IDs. + +## Implementation freedom and scope + +The required outcome, invariants, applicable mandatory requirements, and acceptance criteria are normative. + +Implementation guidance is not a hidden acceptance criterion. An agent may use an equivalent approach when it satisfies the required outcome, preserves the stated invariants, remains inside the execution envelope, and provides the required evidence. The agent must explain a material deviation from the recommendation. + +A reviewer MUST NOT reject an equivalent correction solely because it does not follow optional implementation guidance. + +A review finding does not widen the agent's authority or the original Issue scope. If every safe correction requires an architecture, baseline, permission, destructive-action, external-effect, resource, or other out-of-envelope change, the agent must stop, explain the minimum required expansion, and request the applicable owner decision. + +## Blocking finding template + +```md +### RH-01 - + +Disposition: blocking + +Evidence and reproduction: +- + +Violated contract: +- + +Cause: +- Status: confirmed | likely | unknown +- + +Required outcome: +- + +Invariants and scope guard: +- +- + +Implementation guidance: +- Recommended: +- Acceptable alternatives: + +Verification: +- + +Acceptance criteria: +- +``` + +## Agent correction report + +After addressing a review, the implementation agent writes one compact correction report in the Pull Request. It maps every blocking finding ID to the correction and evidence. + +Use the template in `ai/TASK_REPORT_PROTOCOL.md`. + +The agent may mark a finding `addressed`, `disputed`, `blocked`, or `not-addressed`. + +- `addressed` means the agent believes the correction contract is satisfied; +- `disputed` means the agent provides evidence that the finding, violated contract, or required outcome is incorrect or inapplicable; +- `blocked` means a verified boundary prevents a safe in-envelope correction; +- `not-addressed` means the finding remains open. + +`addressed` does not mean `verified` and does not automatically resolve a review thread. + +## Verification lifecycle + +Finding state is distinct from Pull Request state: + +```text +open -> addressed -> verified +``` + +Only the reviewer or another authorized maintainer marks a blocking finding `verified`. Failed verification reopens the finding with updated evidence. + +`disputed`, `blocked`, and `not-addressed` remain open until the reviewer withdraws the finding, an authorized owner accepts the relevant outcome or risk, or a correction is addressed and verified. + +The normal Pull Request label transition is: + +```text +in-review -> changes-requested -> in-review -> ready-to-merge +``` + +Return the Pull Request to `in-review` after the correction report and required checks are available. Move it to `ready-to-merge` only after every blocking finding is verified or otherwise validly dispositioned and required checks pass. + +## Proportionality + +The complete correction contract is mandatory only for blocking findings. + +Non-blocking findings and questions may remain concise, but must be clearly classified. Optional suggestions belong in follow-up work when they would expand the current scope or delay the primary outcome. + +This protocol does not require automated semantic scoring of review quality, a repository file for every review, or a new Issue for every correction cycle. diff --git a/ai/TASK_REPORT_PROTOCOL.md b/ai/TASK_REPORT_PROTOCOL.md index 7139240..b958f52 100644 --- a/ai/TASK_REPORT_PROTOCOL.md +++ b/ai/TASK_REPORT_PROTOCOL.md @@ -2,7 +2,7 @@ type: task_report_protocol version: 1 status: active -updated: 2026-07-26 +updated: 2026-07-27 project: Agent_Handoff --- @@ -24,12 +24,40 @@ Risk reporting must distinguish verified blocking High or Critical risk, time-bo Every result report must identify the primary outcome, outcome progress, acceptance proof, supporting work, verified blocker, and next direct outcome step. +When an agent addresses blocking review findings, it must also write one Agent Handoff Review Correction Report in the Pull Request. + ## Stage work A stage result is appropriate only when the primary outcome materially advanced, the smallest acceptance proof completed, a verified blocker remains outside the execution envelope, or work is genuinely interrupted or transferred. A supporting-tool failure or localized repair is not a stage by itself. Summarize routine supporting fixes and bounded post-fix verification in the next legitimate stage or final report. +## Review correction report + +A correction report maps every blocking finding ID to the implementation response and verification evidence. It does not replace the required stage or final result comment and does not create an additional outcome stage by itself. + +```md +## Agent Handoff Review Correction Report + +Agent ID: +Run ID: +Reviewed head: +Correction head: + +### RH-01 + +Status: addressed | disputed | blocked | not-addressed +Change: +Implementation choice: +Evidence: +Preserved invariants: +Remaining concern: +``` + +Repeat the finding section for every blocking finding. + +`Addressed` means the agent believes the correction contract is satisfied. It is not reviewer verification and must not automatically resolve a review thread. + ## Stage result comment ```md diff --git a/ai/handoffs/2026-07-27_issue-18_pr-19_run-20260727-issue-18-5a1c.md b/ai/handoffs/2026-07-27_issue-18_pr-19_run-20260727-issue-18-5a1c.md new file mode 100644 index 0000000..d2db58a --- /dev/null +++ b/ai/handoffs/2026-07-27_issue-18_pr-19_run-20260727-issue-18-5a1c.md @@ -0,0 +1,81 @@ +--- +type: handoff +version: 1 +date: 2026-07-27 +updated: 2026-07-27 +run: 20260727-issue-18-5a1c +agent: Review Lynx +agent_id: review-lynx-5a1c +project: Agent_Handoff +branch: actionable-review-protocol +issue: 18 +pr: 19 +base_commit: bd487efa075f1adc970a807ad821b61ce3e28189 +implementation_commit: 5d45454bdf8aba828c990eb338b0769bdedd93c3 +status: completed +relevance: active +supersedes: 20260726-issue-16-8f2c +--- + +# Handoff: Standard 1.5.1 actionable review correction + +## Primary outcome + +Prepare and publish Agent Handoff Standard 1.5.1 so a blocking review can be handed to a coding agent as a self-contained, verifiable correction task without unnecessarily prescribing one implementation. + +## Smallest acceptance proof + +The standard, review protocol, task report, GitHub workflow, handoff rules, Pull Request checklist, structural checker, public documentation, and release metadata agree on the blocking correction contract and `open -> addressed -> verified` lifecycle. + +## Reason for the change + +Standard 1.5 defined when work and findings may block progress, but not how a reviewer transfers an eligible blocking finding back to an implementation agent. + +A bare defect statement could require another agent to reconstruct reproduction, contract, invariants, scope, and proof from chat history. Treating only the reviewer-proposed implementation as acceptable could instead create a hidden acceptance criterion and reject equally safe solutions. + +## What changed + +- Added `ai/REVIEW_PROTOCOL.md`. +- Classified findings as `blocking`, `non-blocking`, or `question`. +- Required stable IDs and sufficient correction contracts for blocking findings. +- Required cause confidence as `confirmed`, `likely`, or `unknown`. +- Kept implementation guidance optional and non-binding for equivalent safe corrections. +- Selected regression, negative, security, and race tests by applicability. +- Added the Agent Handoff Review Correction Report mapped by finding ID. +- Separated agent-reported `addressed` from reviewer-confirmed `verified`. +- Kept review findings inside the original authorization and execution envelope. +- Updated the standard, workflow, reporting, agent guidance, Pull Request checklist, structural checker, project memory, public documentation, citation metadata, changelog, and release notes for Standard 1.5.1. + +## Validation + +- `python3 scripts/check_agent_handoff.py` - passed. +- Python syntax compilation for `scripts/check_agent_handoff.py` - passed. +- `git diff --check` - passed. +- Relative Markdown link validation - passed. +- Active-version scan found no stale 1.5 metadata; remaining 1.5 references are historical or explain the 1.5.1 delta. + +## Scope preserved + +- No application runtime, Docker, Compose, GUI code, or repository settings changed. +- No existing security control, proportional-security threshold, or approval boundary was weakened. +- No automated semantic scoring of review quality was added. +- No long mandatory template was imposed on non-blocking findings or questions. +- No test category was required mechanically for every finding. +- GitHub reviews and review threads remain the source of work truth. + +## Risks + +- Blocking: none verified. +- Investigation: none. +- Follow-up hardening: none required for this change. +- Accepted: none. + +## Next direct outcome step + +Complete GitHub Actions and owner review on Pull Request #19, squash-merge the verified branch, then create tag `v1.5.1` and publish the GitHub Release from the merge commit. + +## Links + +- Issue: https://github.com/artyomboyko/Agent_Handoff/issues/18 +- Pull Request: https://github.com/artyomboyko/Agent_Handoff/pull/19 +- Release notes: `docs/releases/v1.5.1.md` diff --git a/ai/handoffs/INDEX.md b/ai/handoffs/INDEX.md index 38e16b1..b6873a3 100644 --- a/ai/handoffs/INDEX.md +++ b/ai/handoffs/INDEX.md @@ -2,7 +2,7 @@ type: handoff_index version: 1 status: active -updated: 2026-07-26 +updated: 2026-07-27 project: Agent_Handoff --- @@ -12,7 +12,8 @@ Read this index first. | Date | Updated | Run | Issue | PR | Branch | Status | Relevance | Summary | File | Supersedes | |---|---|---|---|---|---|---|---|---|---|---| -| 2026-07-26 | 2026-07-26 | 20260726-issue-16-8f2c | #16 | #17 | outcome-oriented-execution | completed | active | Prepared Standard 1.5 with outcome-oriented execution and bounded supporting work | 2026-07-26_issue-16_pr-17_run-20260726-issue-16-8f2c.md | 20260724-issue-14-7d2a | +| 2026-07-27 | 2026-07-27 | 20260727-issue-18-5a1c | #18 | #19 | actionable-review-protocol | completed | active | Prepared Standard 1.5.1 with actionable blocking review correction contracts | 2026-07-27_issue-18_pr-19_run-20260727-issue-18-5a1c.md | 20260726-issue-16-8f2c | +| 2026-07-26 | 2026-07-26 | 20260726-issue-16-8f2c | #16 | #17 | outcome-oriented-execution | completed | historical | Prepared Standard 1.5 with outcome-oriented execution and bounded supporting work | 2026-07-26_issue-16_pr-17_run-20260726-issue-16-8f2c.md | 20260724-issue-14-7d2a | | 2026-07-24 | 2026-07-24 | 20260724-issue-14-7d2a | #14 | #15 | proportionate-security-evidence | completed | historical | Prepared Standard 1.4 with a verified High/Critical security-work threshold | 2026-07-24_issue-14_pr-15_run-20260724-issue-14-7d2a.md | publish-standard-1-3-20260718 | | 2026-07-18 | 2026-07-18 | publish-standard-1-3-20260718 | #12 | #13 | standard-1.3 | completed | historical | Published Standard 1.3 with containerization decision gate and safe GUI testing rules | 2026-07-18_issue-12_pr-13_run-publish-standard-1-3-20260718.md | english-only-cleanup | | 2026-07-07 | 2026-07-07 | english-only-cleanup | none | none | main | completed | historical | Simplified active repository files to English-only documentation | | repository-presentation | diff --git a/docs/PROMOTION_CHECKLIST.md b/docs/PROMOTION_CHECKLIST.md index ca93d64..d3baf09 100644 --- a/docs/PROMOTION_CHECKLIST.md +++ b/docs/PROMOTION_CHECKLIST.md @@ -4,8 +4,8 @@ Reusable checklist for publishing Agent Handoff releases. ## Current release -- Standard 1.5 is active in `AGENT_HANDOFF_STANDARD.md`. -- README, citation metadata, changelog, release notes, project state, and public documentation identify version 1.5. +- Standard 1.5.1 is active in `AGENT_HANDOFF_STANDARD.md`. +- README, citation metadata, changelog, release notes, project state, and public documentation identify version 1.5.1. - Repository checks validate active standard metadata and release-note presence. ## Public repository checks diff --git a/docs/en/FAQ_EN.md b/docs/en/FAQ_EN.md index ba6d98f..132a824 100644 --- a/docs/en/FAQ_EN.md +++ b/docs/en/FAQ_EN.md @@ -7,3 +7,11 @@ Agent Handoff FAQ. Test harnesses, smoke wrappers, evidence collectors, CI scaffolding, and similar tools usually exist to enable or prove another outcome. Turning every localized failure into a separate stage, handoff, or approval cycle can advance the process without advancing that outcome. Agent Handoff therefore keeps reversible in-scope repairs and bounded post-fix verification inside the original execution envelope. The envelope records existing authorization and cannot be used by an agent to grant itself broader authority. A new owner decision is still required when the outcome, scope, architecture, accepted baseline, external effects, resource or risk boundary, security baseline, or enforced permission gate changes. + +## What makes a blocking review actionable for an agent? + +A blocking review gives each finding a stable ID and enough evidence, contract, outcome, invariant, scope, verification, and acceptance information for another agent to correct it without private chat history. + +Implementation guidance remains non-binding when an equivalent safe correction satisfies the required outcome, preserves invariants, stays inside the execution envelope, and provides the required evidence. + +Agent-reported `addressed` status still requires verification by the reviewer or another authorized maintainer. diff --git a/docs/en/PROMOTION_CHECKLIST_EN.md b/docs/en/PROMOTION_CHECKLIST_EN.md index 8b40fb9..159f812 100644 --- a/docs/en/PROMOTION_CHECKLIST_EN.md +++ b/docs/en/PROMOTION_CHECKLIST_EN.md @@ -4,8 +4,8 @@ This page mirrors `docs/PROMOTION_CHECKLIST.md` for English documentation reader ## Current release -- Standard 1.5 is active in `AGENT_HANDOFF_STANDARD.md`. -- README, citation metadata, changelog, release notes, project state, and public documentation identify version 1.5. +- Standard 1.5.1 is active in `AGENT_HANDOFF_STANDARD.md`. +- README, citation metadata, changelog, release notes, project state, and public documentation identify version 1.5.1. - Repository checks validate active standard metadata and release-note presence. ## Public repository checks diff --git a/docs/en/README.md b/docs/en/README.md index 2632bec..8da3d94 100644 --- a/docs/en/README.md +++ b/docs/en/README.md @@ -1,11 +1,11 @@ # English documentation -This page is the documentation index for Agent Handoff Standard 1.5. +This page is the documentation index for Agent Handoff Standard 1.5.1. ## Documents - [Standard](../../AGENT_HANDOFF_STANDARD.md) -- [Release notes 1.5](../releases/v1.5.md) +- [Release notes 1.5.1](../releases/v1.5.1.md) - [Issue labels](../../ISSUE_LABELS.md) - [Issue status](../../ISSUE_STATUS.md) - [Guide](../../AGENTS.md) @@ -15,6 +15,7 @@ This page is the documentation index for Agent Handoff Standard 1.5. - [Agent identity](../../ai/AGENT_IDENTITY.md) - [Work claim protocol](../../ai/WORK_CLAIM_PROTOCOL.md) - [Task report protocol](../../ai/TASK_REPORT_PROTOCOL.md) +- [Review protocol](../../ai/REVIEW_PROTOCOL.md) - [Project state](../../ai/PROJECT_STATE.md) - [Decisions](../../ai/DECISIONS.md) - [Refactoring workflow](../../ai/REFACTORING.md) @@ -46,6 +47,16 @@ Supporting work stays minimum sufficient. A localized, reversible supporting-too One bounded verification rerun after an evidence-based fix is permitted unless the execution envelope sets a stricter limit. After two consecutive supporting-only updates without outcome progress, the agent marks the work `progress-stalled` and replans the shortest path. +## Actionable review handoff + +A blocking finding must give another agent a self-contained correction contract: stable ID, evidence or reproduction, violated contract, cause confidence, required outcome, preserved invariants, scope guard, minimum applicable verification, and observable acceptance criteria. + +Cause confidence is marked `confirmed`, `likely`, or `unknown`. Implementation guidance remains non-binding when an equivalent safe correction satisfies the required outcome, preserves invariants, remains inside the execution envelope, and provides the required evidence. + +The implementation agent maps every blocking finding ID to its change and evidence in one correction report. Agent-reported `addressed` status does not resolve the finding; the reviewer or another authorized maintainer marks it `verified`. + +The complete contract is required only for blocking findings. Non-blocking suggestions and questions may remain concise but must be classified clearly. + ## Mandatory containerization question For both a new repository and an existing repository, the coding agent must ask a separate, explicit question about Docker and Docker Compose organization before changing any container files or paths. @@ -72,6 +83,11 @@ Record the primary outcome, smallest acceptance proof, and execution envelope be Keep supporting work minimum sufficient. Fix localized reversible supporting-work failures and perform bounded post-fix verification inside the same work item. Do not create a separate stage, handoff, completion target, or approval gate for a supporting-tool failure alone. +When requesting changes in a Pull Request, classify findings as blocking, non-blocking, or questions. +Give each blocking finding a stable ID and a sufficient correction contract. +Treat implementation guidance as non-binding when an equivalent safe correction satisfies the outcome and invariants. +Keep agent-reported addressed status separate from reviewer verification. + Create the first short handoff and update the handoff index. ``` @@ -97,5 +113,10 @@ Record the primary outcome, smallest acceptance proof, and execution envelope be Keep supporting work minimum sufficient. Fix localized reversible supporting-work failures and perform bounded post-fix verification inside the same work item. Do not create a separate stage, handoff, completion target, or approval gate for a supporting-tool failure alone. +When requesting changes in a Pull Request, classify findings as blocking, non-blocking, or questions. +Give each blocking finding a stable ID and a sufficient correction contract. +Treat implementation guidance as non-binding when an equivalent safe correction satisfies the outcome and invariants. +Keep agent-reported addressed status separate from reviewer verification. + Open a pull request and leave a short handoff. ``` diff --git a/docs/index.html b/docs/index.html index 57dde8f..bb0e8d1 100644 --- a/docs/index.html +++ b/docs/index.html @@ -3,11 +3,11 @@ - Agent Handoff 1.5 — GitHub-native context handoff for AI coding agents - + Agent Handoff 1.5.1 — GitHub-native context handoff for AI coding agents + - - + +