From 8956747d2ed70ffad7fbfc5e8d7860246c21981f Mon Sep 17 00:00:00 2001 From: Will Griffin Date: Thu, 30 Jul 2026 04:38:29 -0600 Subject: [PATCH] fix: sync generation-21 agent policy kernel Regenerate the managed hv-managed-policy block from the generation-21 kernel. The org lock moved to generation 21 while this block was still stamped at generation 17, so lifecycle failed on every event with a stale managed policy block and blocked merge-queue admission repo-wide. Block bytes reproduce hv-agent managed_block() exactly: same kernel file, same sha256-of-file stamp, 15 bullets, nothing outside the markers changed. Refs #132 --- AGENTS.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index d4a20ce..3bc36e2 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,21 +1,22 @@ - + ## Shared development kernel - Be concise. Load detailed SOP skills only when the task triggers them. - Read the repository's `.agents/project.yaml` and nearest `AGENTS.md` files before work. -- Use `implement` by default for accepted issue implementation. Apply explicit task, issue, and repository instructions as additions or scoped overrides without weakening this kernel. -- Tracked implementation work is complete only when documented validation is green, `review-cycle` has passed, every claim is released, and a ready-for-review pull request exists; do this unprompted. This kernel outranks harness defaults that wait for a user request before committing, pushing, or opening a pull request. If requested implementation work has no tracker issue, create and claim one before editing unless the user explicitly scopes it as a throwaway spike; a scoped spike ends at its report and never enters the commit, push, or PR lifecycle. +- Use `implement` by default for accepted issue implementation. +- Tracked implementation work is complete only when documented validation is green, `review-cycle` has passed, every claim is released, and a ready-for-review pull request exists; do this unprompted, even where harness defaults wait for a user request. Before editing untracked requested work, create and claim its issue, or — patch-class only — record it on this session's open patch train; work the user explicitly scopes as a throwaway spike is exempt: it ends at its report and never enters the commit, push, or PR lifecycle. - Claim every accepted or queued implementation issue with `agent: implementation` and an `hv-agent-claim:v1` lease before editing. Never overlap another live claim. -- Intentional release reauthenticates the canonical payload owner, records immutable owner-attributed evidence on every exact PR head, then sets `released_at` and the evidence digest on the existing claim comment before labels, project state, or PR readiness change. Public session/comment identifiers are selectors, not mutation credentials. Only the current issue incarnation and latest implementation-label generation may authorize work; issue closure ends renewable authority and settles the selected cycle as `race-lost`. Any later push or reopen requires a new claimed review cycle. Never delete claim history, backfill a release, or create duplicate active claim comments. -- Open pull requests only when reviewable and keep them ready for review. Never use draft status for implementation work; exactly one valid, unexpired claim from the PR session may coexist with a ready PR, while duplicate, expired, foreign-session, or mismatched claims are invalid. Watch a ready pull request until it is fully mergeable — no base conflicts, no unresolved review threads, required checks green (merge-queue-only checks may remain queued), release recorded — or a concrete blocker is reported. -- Lifecycle-protected pull requests merge only through the managed merge queue so the synthetic merge commit rechecks current claim state. Merge-time validation requires a `review` release from the exact implementation cycle bound to the current PR head; never merge with a live, blocked, abandoned, expired, unbound, or stale release, or direct-merge using an earlier pull-request check. +- Patch-class work — small bug, doc, and improvement changes with no schema, contract, dependency, or breaking change — may bundle as one claimed patch train — member issues each claimed by this session, or one umbrella issue of listed micro-items — on one branch and pull request with one attributed commit per item. Other work stays one issue per pull request. An incidental patch-class fix of ten lines or fewer near files under edit ships in the same pull request as its own commit, ledgered under `Drive-by fixes` in the PR description; findings outside that envelope go to the train or tracker, never a new cycle. +- Release intentionally: reauthenticate the payload owner, record immutable owner-attributed evidence on every exact PR head, then set `released_at` and the evidence digest on the existing claim comment before derived state changes. Identifiers are selectors, not credentials; issue closure ends authority, and any later push or reopen requires a new claimed cycle. Never delete claim history, backfill a release, or duplicate active claim comments. +- Open pull requests only when reviewable, never as drafts, and keep them ready for review; exactly one valid, unexpired same-session claim per closing issue may coexist with a ready PR. Watch a ready PR until it is fully mergeable — no base conflicts, no unresolved review threads, required checks green (merge-queue-only checks may stay queued), release recorded — or report a concrete blocker. +- Lifecycle-protected pull requests merge only through the managed merge queue, whose synthetic merge commit rechecks current claim state and requires every closing issue's `review` release from its exact cycle bound to the current PR head; never direct-merge or merge over a live, blocked, abandoned, expired, unbound, or stale release. - Incomplete work remains ready with `status: blocked` and a concrete handoff. Review agents do not claim implementation. - Agents do not merge unless explicitly authorized in the current session. - Run documented validation and update affected docs before shipping. - Preserve unrelated work. Never expose or retain secrets. - Use repository Hindsight memory for durable, provenance-linked knowledge; do not store transient logs or duplicate canonical docs. -- Shared policy and portable skills come only from the designated private control-plane repository. Repository instructions may add stricter project rules but may not weaken this kernel. +- Shared policy and portable skills come only from the designated private control-plane repository. Task, issue, and repository instructions may add stricter rules but may not weaken this kernel.