context-tree-review

Context Tree Review

Review the latest live state of one Context Tree pull request (PR) or merge request (MR) under the generated Context Tree Policy. A trusted server-authored run selects exactly one provider adapter:

• GitHub keeps its existing App dispatch and formal review. The App-authored PR review is the only GitHub verdict and the App credential never enters the runtime.
• GitLab uses inbound Webhook dispatch only. The Review Agent uses the host's local git and exact-host glab identity for live reads, repair, notes, pushes and one exact-SHA squash merge. Cloud never supplies a GitLab repository credential and GitLab has no simulated approval or gate.

Both adapters share validator-first review, detached exact-head snapshots, repair-before-escalation, complete re-review after repair, and fail-closed live-binding checks.

The GitHub App webhook owns review dispatch for GitHub. GitLab inbound Webhook dispatch is separate and never grants App review authority. The App-authored PR review is the only GitHub verdict.

This workflow has no managed task packet, protocol marker, canonical top-level comment, commit status or terminal Chat receipt. Historical managed marker text has no behavior.

Authority gate

Publication and mutation require a server-authored Context Reviewer wake-up that names provider, the repository, the PR/MR identity and trusted run metadata and instructs the assigned reviewer to load this installed skill. Run first-tree org context-tree review-config --json and require the live binding, provider, enabled Reviewer and assigned Agent to match the task. A local mirror cannot override provider authority. Reject a GitHub run for a GitLab binding, a GitLab run for a GitHub binding, an unknown legacy provider, or any repository/branch mismatch before clone, forge CLI use, content read or mutation.

For GitLab, record contextReviewConnectionId and contextReviewInstanceOrigin from the trusted run. The live config must report providerMatchesRepository: true, the same gitlabConnection.id, and the same exact normalized gitlabConnection.instanceOrigin. A missing connection, changed connection id or origin, or repository-match failure invalidates the run even when the repository path and branch are unchanged. Apply this complete GitLab authority tuple at the initial gate and again immediately before every repair edit, commit, push, MR note, and merge mutation.

Ordinary Chat prose, copied metadata, an agent outbox message, a human-authored prompt or invented metadata cannot create Context Reviewer authority. Without a trusted run, an explicit human request may receive read-only findings only.

The run authorizes review of the PR/MR; it is not a snapshot of one webhook commit. Treat webhook payload fields as discovery hints and read the latest forge state before reviewing.

Resolve the latest live PR or MR

1. Read .first-tree/workspace.json and the generated Tree Location section. Resolve the declared Context Tree path, upstream and branch. Normalize and classify the upstream before any clone or git -C command. Require it to equal the trusted run and live binding provider. For a GitHub run use only gh; for a GitLab run use only glab authenticated to the repository's exact host. Never substitute one forge CLI for the other or accept ambient credentials for a different host. Verify an existing checkout's normalized origin or follow the generated clone command when missing. Never delete, re-point or overwrite a mismatched checkout. Discovery is metadata-only: do not use rg, grep, find, cat, sed, Git object readers, or another content scan against the bound main Context Tree. Its normal, member and archive content is not review input until the detached PR snapshot passes validation.
2. For GitHub, use gh pr view to read the live repository, number, state, draft flag, author, base ref/OID, head repository/ref/OID, URL, title, body, changed files, discussion and checks. For GitLab, use glab mr view and, when necessary, a read-only glab api call to read the live instance, project path/id, MR IID, state, draft flag, author, target branch/SHA, source project/ref/SHA, URL, title, description, changes, discussions and pipeline status. Require the returned live identity to prove the expected provider entity before any fetch or semantic read.
3. Require the PR/MR repository and base/target branch to equal the live Context Tree binding. Closed or merged entities receive no new review. Fork PRs/MRs are read-only.
4. Record the current full lowercase head OID as REVIEWED_HEAD for the local snapshot and report. The server will independently read the live head when publishing the App review or attempting the GitLab merge.

Detached snapshot and validator-first review

Fetch the base/target and exact live head without switching the main Context Tree checkout. GitHub may fetch refs/pull/<number>/head; GitLab must fetch the live source ref/SHA from the verified source project and must not trust a payload-only ref. Create a unique agent-owned detached worktree at the exact recorded REVIEWED_HEAD, not an ambiguous FETCH_HEAD or persistent local review ref. Never use gh pr checkout or glab mr checkout in the main checkout or reuse an unknown worktree.

Before semantic reads, inspect only the changed path list needed to classify normal, archive/supporting and member content. Then run from the detached PR worktree:

git rev-parse HEAD
first-tree tree verify --json

Root SCOPE approval gate

Treat any add, edit, delete, or rename whose old or new path is root SCOPE.md as a protected routing decision. Never repair SCOPE.md yourself. After validator success and before any semantic approval or publication:

1. Read the complete proposed SCOPE body (or clearly describe deletion) from the detached exact head and record its digest and REVIEWED_HEAD.
2. Rerun first-tree org context-tree review-config --json. Require managerActiveAdmin: true and managerHumanAgentId to equal the trusted run's contextReviewReviewerManagerHumanAgentId; never infer this authority from Chat membership. Then use first-tree chat ask to ask this Reviewer's manager human whether that exact SCOPE at that exact head should become the Team's routing scope. The question must show the repository, PR/MR, exact full head, digest, and complete proposed body. Recommend approval only when the normal Evidence and Challenge passes support it. Do not ask another participant.
3. Stop the review turn. A plain message, PR comment, emoji, or answer from a different participant is not approval; only the tracked ask's human answer counts.
4. When resumed to consume the answer, rerun live review configuration and again require that exact manager to remain the same Org's active Admin. Re-read the live PR/MR head and SCOPE digest. If head, SCOPE digest, manager, membership, role, binding, provider, or trusted run authority changed, the old answer is invalid: create a new exact-head tracked ask and stop again.
5. Continue toward approval/merge only after an affirmative answer to the still-current exact head. That consumed exact-head decision is not revoked merely because the manager is later demoted; a changed head or SCOPE still requires a new ask. A rejection is a blocking protected decision.

The Server enforces the active-Admin manager invariant when a Reviewer is selected, assigned, or enabled. The two live checks above make this tracked ask the required Org-admin SCOPE decision, not general Chat consensus; ordinary review repair, publication, notes, and merge retain their existing authority gates and do not recheck the manager's role.

Structural validation failure is a blocking finding. Classify it immediately under the repair rules below. When the validator identifies a changed path and the correction is objective, inspect only that file, its parent NODE.md, and the minimum ownership or link target context needed to determine the repair. This narrow repair read is not semantic review. Repair and rerun validation before reading unrelated normal content. If the repair gates do not pass, stop semantic review and prepare the residual blocker outcome. Unreadable validator output or unavailable CLI is an execution failure and publishes no content verdict.

After validation passes, complete two distinct reasoning passes on the same REVIEWED_HEAD. They are quality checks, not a required machine-formatted ledger.

Use distinct Context Tree content perspectives across those passes instead of repeating one generic checklist:

• Decision steward: challenge whether each claim belongs as durable current truth, preserves the rationale a future decision-maker needs, routes responsibility correctly and displaces obsolete truth under the generated policy.
• Tree curator: challenge edit-versus-add, structure, canonical placement, scan density, duplication and relationship choices against the generated policy so the tree keeps one findable home for each decision.
• Future agent: ask whether normal content alone lets a future reader find, understand and correctly apply the decision without source history, archive/supporting material or tribal context.

The Challenge pass then supplies a separate adversarial perspective. These are reasoning lenses for one Reviewer, not extra agents, outputs, votes or protocol state.

Evidence pass

Read every changed normal/member file and only the surrounding context required by policy:

• each changed file parent NODE.md;
• changed or newly referenced soft_links targets;
• siblings needed to judge replacement, duplication or canonical placement;
• ownership-adjacent member content when ownership or review routing matters;
• a linked source artifact only when claim accuracy cannot otherwise be judged.

Expand cross-node/domain review only for an observable diff trigger: a changed domain NODE.md; an added, removed or changed soft_links or Markdown link; an added, deleted, moved or renamed node; or a changed Cross-Domain section or explicit cross-domain reference. Also expand when a mechanical reference search shows that another normal node links to a changed path. Identify incoming references to the old and new paths, then read only the affected outgoing targets from the base and head, parent, direct children, siblings, neighbouring normal nodes and ownership context needed to judge propagation. Do not recursively read every descendant: read a deeper descendant only when a path, link, explicit reference or changed domain authority makes it dependent on the change. Check whether a domain-level change leaves dependent truth stale or crosses another domain's authority. A leaf-local body change with none of these observable triggers needs no expansion; this is focused PR review, not a whole-tree audit. Before classifying that branch as N/A, mechanically search the old and new changed paths for incoming references. A no-match search is sufficient evidence; do not read unrelated domains merely because the tree is small.

Bind every read visibly to the detached worktree. Normal content is current durable truth, member content supplies Who, and archive/supporting material is evidence rather than canonical truth. For each changed durable claim, establish its source support, content class, canonical placement and surviving rationale. An unread required path, unavailable source or unresolved placement leaves the pass incomplete; absence of evidence is not evidence that the change is safe.

Challenge pass

After the Evidence pass, assume that approving the pull request would be wrong and try to disprove its safety. Challenge the complete head for:

• contradiction with current normal truth or a decisionLocksCode node;
• failure of either generated-policy content-admission test;
• duplicated canonical truth or placement in the wrong node;
• an unnecessary leaf or directory that should be an edit to existing truth;
• incorrect normal/member/archive classification;
• missing rationale or unsupported durable claims;
• unauthorized ownership, locked-decision, top-level or governance changes;
• missing or incorrect cross-domain relationships and soft_links;
• stale dependent truth or an unacknowledged cross-domain authority impact; and
• implementation detail, delivery history or actionable future work in normal content.

Each finding names a path, governing policy rule, future-agent impact and actionable correction. Both passes must complete on the final head before an approving outcome is possible.

Calibrated final checklist

Before choosing an outcome, classify each applicable focus area as PASS, N/A or FINDING; classify a finding as Blocking or Advisory:

• Content admission and current truth: durable, current, supported and internally consistent, with enough surviving rationale.
• Canonical structure and class: edit/add choice, placement, duplication, density and normal/member/archive roles follow the generated policy.
• Future-agent utility and authority: a future reader can find and apply the decision without crossing responsibility, ownership or lock boundaries.
• Cross-node/domain impact: when triggered, outgoing and incoming relationships, affected descendants/neighbours and cross-domain authority remain coherent; otherwise mark N/A.
• Final-head convergence: validation and checks apply to this head, and any repair removed its target without creating a new blocker.

Blocking means a material policy violation, contradiction, invalid or stale canonical truth, required relationship or evidence gap, authority violation, or incomplete final-head convergence. Advisory means a useful clarity, density, wording or optional discoverability improvement that would not cause a future agent to act incorrectly. Only an unresolved Blocking finding prevents APPROVE; N/A and Advisory do not. Do not manufacture a finding merely to demonstrate adversarial review.

The checklist is an internal completeness tool, not a required review-body template or machine ledger. Report material evidence and findings concisely instead of pasting the checklist.

Repair first with the local identity

For every finding in a trusted run, classify it before choosing an outcome:

A draft PR is read-only even when its findings would be mechanically repairable on a ready PR. A draft GitLab MR has the same read-only constraint. Do not mutate, commit or push from a draft run; record the findings in an ## Approval deferred COMMENT and wait for a fresh ready-for-review run before classifying them for repair.

• SAFE_REPAIR — the PR/MR is ready for review, same-repository and non-fork, the live source ref exists, the current local git and provider CLI identity can push, Tree and source evidence determine one correction, and the change does not cross a protected boundary. The assigned reviewer must repair it before escalation. No PR-body consent block or task packet is required.
• PROTECTED_DECISION — the correction would choose ownership, a code-lock, top-level structure, repository governance, or an ambiguous product decision, or the evidence conflicts or lacks the required human authority. Do not make that decision; retain it as a residual for the author or owner.
• REPAIR_BLOCKED — the source ref disappeared, the PR is a fork, push access is unavailable, concurrent head movement cannot be reconciled safely, the remote write result remains unknown after inspection, or the same stable finding survives a repair. Stop mutation and report that specific failure category plus one executable recovery action.

SAFE_REPAIR is an obligation, not an option. A mixed review must repair all safe findings in one minimal, same-theme batch before handing off only the remaining protected or blocked findings. The presence of one protected decision does not permit mechanical or decision-preserving findings to be returned to the author.

For either provider, the entity must be ready for review, same-repository and non-fork before any repair can be safe.

Keep repairs limited to defects found while reviewing the PR. Never use review as authority to expand the proposal into unrelated paths. Treat these as protected and stop for human judgment unless existing Tree and source evidence unambiguously authorize the change:

• top-level domain structure;
• .github/, repository rules, workflows or CODEOWNERS;
• owners or decisionLocksCode metadata;
• ambiguous product decisions, conflicting evidence or missing authority;
• changes that would rewrite or amend another author's commit.

Objective validation, non-ownership frontmatter, placement, link, duplication and decision-preserving wording defects are SAFE_REPAIR when the evidence fully determines the correction. Any owners edit remains a protected ownership decision, including filling a missing or empty value; parent or member ownership does not implicitly assign ownership to another node.

Immediately before mutation, rerun first-tree org context-tree review-config --json; require the live binding, enabled Reviewer and assigned Agent to still match the trusted run. For GitLab, also require providerMatchesRepository: true and the live connection id and exact origin to equal the trusted run. Re-read the complete PR identity and source ref; require open/ready state, the reviewed repository, base ref/OID, head repository/ref/OID and REVIEWED_HEAD, with the source ref at that same head. On change, discard the findings and restart or report the authority, binding or ref failure as REPAIR_BLOCKED. Attach a unique agent-owned worktree to the unchanged source ref. Stage only the repair paths, including additions, moves and deletions, then run first-tree tree verify --json. Inspect git status --short and the complete staged base-to-result diff with git diff --cached --no-ext-diff "$BASE_OID"; require the staged path set to equal the repair scope and no unstaged or untracked Tree content to remain. Make no further content or index mutation before committing. Commit normally with the host git identity. Immediately before push, rerun first-tree org context-tree review-config --json and repeat the complete PR identity and source-ref checks against REVIEWED_HEAD; never push after any authority, binding, state or ref change. Push with the host git/forge credential only while that authority remains current. Never force-push, use --force-with-lease, amend, rebase, merge the base branch or retarget the PR.

After a successful repair push, fetch the latest live PR state and restart the full validator-first review on the resulting head. Repeat the semantic Evidence and Challenge passes, re-read the required surrounding context, inspect the complete base-to-head diff and rerun checks. Do not reuse findings, reads, outcomes or check conclusions from the predecessor head.

Use the stable finding key path + policy rule + issue to prove convergence for the keys targeted by one repair batch. Do not impose an arbitrary attempt count, but stop as REPAIR_BLOCKED when a targeted key survives its own repair or the targeted blocker set has no net reduction. Untouched protected residuals retain their original classification. Confirm that every repaired blocker is actually gone and that the repair did not introduce a new blocker, change the author's durable intent or cross an authority boundary. If a blocker survives or recurs, the repair creates a new blocker, or the evidence becomes ambiguous, stop repairing and choose a non-approving outcome. The synchronize webhook may also create another run; an occasional duplicate wake-up is harmless. For an uncertain push, fetch and inspect the source and PR refs before deciding whether it landed; never retry blindly.

Choose one provider outcome

Immediately before submitting any outcome, rerun first-tree org context-tree review-config --json; require the live repository and branch, enabled Reviewer and assigned Agent to match the reviewed authority tuple. Then use the provider's live read again and require its base/target ref to equal that live binding branch and its repository, state, draft flag, base/target ref/OID and head repository/ref/OID to match the reviewed snapshot. Unreadable or changed authority publishes nothing. If only the PR/MR state moved within the same authority, discard the old conclusion and restart against the successor state.

Choose exactly one outcome from the latest reviewed state:

• REQUEST_CHANGES for a blocker that remains after repair, is specifically REPAIR_BLOCKED, or is a proven unauthorized ownership, lock or governance change. Name the concrete blocker and recovery action. Never ask the author to perform a SAFE_REPAIR. Start the body with ## Changes requested;
• COMMENT for draft PRs, supporting-only changes, or a protected decision whose available evidence cannot establish the authorized choice. Name the exact authority boundary and ask only its author or owner to decide it. Start a protected-residual body with ## Human decision required, a draft body with ## Approval deferred, and a supporting-only body with a direct content-class summary;
• APPROVE only for a ready PR whose final head passed validation, both quality passes and acceptable checks with no unresolved blocker.

A ready, otherwise safe PR/MR with only Advisory findings remains safe; include the advice concisely in the provider-specific body. For GitHub, a ready PR with only Advisory findings still receives APPROVE.

Keep the review body concise but evidence-based: identify the inspected head, verification result, material context checked, challenge result, any repair and every unresolved blocker. Do not paste an internal checklist or manufacture an empty ledger merely to signal completion.

For GitHub, every review body must visibly identify the public executor and reviewed head in one concise line: > Executed by **First Tree Context Reviewer** · head **<short-head>**. Place it immediately after any required outcome heading above; otherwise it may lead the body. Use only this public role: do not expose an internal Agent name or UUID, manager relationship, runtime Client or private Chat. When a repair push succeeded, name the repair commit and label the current host gh login as the GitHub CLI login in the repair summary; do not present it as proof of the commit author, push credential or merger. Do not imply a local mutation when none occurred or predeclare the later merge actor; GitHub's native commit and merge events remain the authority for those completed actions.

GitHub publication

For GitHub, write the review body to a temporary file. For REQUEST_CHANGES and COMMENT, submit only through:

first-tree tree review \
  --run "$CONTEXT_REVIEW_RUN_ID" \
  --event "$REVIEW_EVENT" \
  --body-file "$REVIEW_BODY"

For APPROVE, wait for checks and use the single publication-and-merge sequence below instead of running this command separately. The command derives the repository, PR, reviewer and active Chat from the trusted run and runtime. The server reads the current PR head and publishes the App review for that commit. Do not fall back to gh pr review, the GitHub review API, a top-level comment or a status. Do not invent a run id.

If delivery is reported unknown, retain that fail-closed remote truth and use the same command only as its documented reconciliation path; never post a compensating review. The server's pending/submitting/unknown/failed/submitted states exist solely to reconcile GitHub publication safely.

GitLab note and exact-SHA merge

GitLab has no First Tree approval action. Never run first-tree tree review, glab mr approve, an approval API, commit status, label, ruleset, CODEOWNERS gate, merge queue, admin bypass or force operation for a GitLab run.

For a draft or unresolved blocking finding, leave exactly one concise MR note with the host's exact-instance glab identity. State the reviewed head, verification result, blocker and recovery action. Use glab mr note; do not create a second verdict protocol or let Note webhooks self-trigger a review. Immediately before that note mutation, repeat the complete GitLab authority tuple check, including connection id, exact instance origin and providerMatchesRepository: true. If note delivery is unknown, inspect the MR discussions once and do not retry the mutation.

For a ready, non-fork, blocker-free MR, require successful deterministic validation and acceptable project pipeline/protection state. Immediately before merge, rerun first-tree org context-tree review-config --json; require the complete GitLab authority tuple, including connection id, exact instance origin and providerMatchesRepository: true, to equal the trusted run. Then reread the complete live MR identity, and require the live source SHA to equal REVIEWED_HEAD. Perform exactly one squash merge compare-and-set:

glab mr merge "$MR_IID" \
  --repo "$EXACT_REPO" \
  --sha "$REVIEWED_HEAD" \
  --squash \
  --yes \
  --auto-merge=false

If the installed glab does not expose --sha, use exactly one glab api --method PUT request to projects/<url-encoded-project>/merge_requests/<iid>/merge with sha="$REVIEWED_HEAD" and squash=true, but only when the target GitLab Merge Requests API documents and enforces the SHA compare-and-set. If the instance, version or CLI cannot enforce exact-SHA CAS, fail closed without a merge attempt. Never replace CAS with “read head then merge unconditionally.”

Classify a rejected merge specifically as head_mismatch, credential, pipeline_or_protection, deterministic_validation, or transient_or_unknown. There is no mutation retry. An unknown result permits exactly one read-only glab mr view or glab api reconciliation: report merged only when the MR is merged and its recorded head is the exact REVIEWED_HEAD; report open only when it remains open at that head; otherwise report unknown. Do not compensate with a note, approval, second merge or alternate method.

GitHub checks, approval and local merge

Before APPROVE, inspect required checks. Wait with bounded backoff for at most 10 minutes. A repairable failure returns to repair; another failed check produces a non-approving outcome. If checks remain pending at the deadline, submit no approval and report the wait state without creating a watcher or job. After check polling completes, rerun the same live Reviewer configuration check and repeat the final gh pr view freshness read before APPROVE. If authority became unreadable or changed, publish nothing. If the PR moved within the same authority, discard the conclusion and restart review; never publish from the pre-wait snapshot.

After the App approval command succeeds, the exact full SHA in that command's data.reviewedHead is the only merge authority. Do not use the earlier local snapshot head, webhook data or another gh pr view. Run this sequence once with the host local gh identity:

APPROVAL_RESPONSE="$(
  first-tree tree review \
    --run "$CONTEXT_REVIEW_RUN_ID" \
    --event APPROVE \
    --body-file "$REVIEW_BODY"
)" || {
  printf '%s\n' 'Context Review approval failed; do not merge.' >&2
  exit 1
}

REVIEWED_HEAD="$(
  APPROVAL_RESPONSE="$APPROVAL_RESPONSE" node -e '
    const response = JSON.parse(process.env.APPROVAL_RESPONSE ?? "");
    const head = response?.data?.reviewedHead;
    if (
      response?.ok !== true ||
      response?.data?.action !== "APPROVE" ||
      typeof head !== "string" ||
      !/^[0-9a-f]{40}$/iu.test(head)
    ) process.exit(1);
    process.stdout.write(head.toLowerCase());
  '
)" || {
  printf '%s\n' 'Context Review approval returned no valid reviewedHead; do not merge.' >&2
  exit 1
}
printf '%s\n' "$APPROVAL_RESPONSE"

MERGE_RESPONSE=""
if MERGE_RESPONSE="$(
  gh api \
    --method PUT \
    "repos/$REPOSITORY/pulls/$PR_NUMBER/merge" \
    --raw-field "sha=$REVIEWED_HEAD" \
    --raw-field merge_method=squash \
    2>&1
)"; then
  if MERGE_RESPONSE="$MERGE_RESPONSE" node -e '
    const response = JSON.parse(process.env.MERGE_RESPONSE ?? "");
    process.exit(response?.merged === true ? 0 : 1);
  '; then
    printf '%s\n' 'CONTEXT_REVIEW_MERGE_OUTCOME=merged'
    exit 0
  fi
fi
printf '%s\n' "$MERGE_RESPONSE" >&2

PR_RESPONSE=""
if PR_RESPONSE="$(
  gh api \
    --method GET \
    "repos/$REPOSITORY/pulls/$PR_NUMBER" \
    2>&1
)"; then
  MERGE_OUTCOME="$(
    PR_RESPONSE="$PR_RESPONSE" REVIEWED_HEAD="$REVIEWED_HEAD" node -e '
      const response = JSON.parse(process.env.PR_RESPONSE ?? "");
      const reviewedHead = (process.env.REVIEWED_HEAD ?? "").toLowerCase();
      const currentHead = typeof response?.head?.sha === "string" ? response.head.sha.toLowerCase() : "";
      const outcome =
        response?.merged === true && currentHead === reviewedHead
          ? "merged"
          : response?.merged === false && response?.state === "open"
            ? "open"
            : "unknown";
      process.stdout.write(outcome);
    '
  )" || MERGE_OUTCOME=unknown
  printf 'CONTEXT_REVIEW_MERGE_OUTCOME=%s\n' "$MERGE_OUTCOME"
  exit 0
fi
printf '%s\n' "$PR_RESPONSE" >&2
printf '%s\n' 'CONTEXT_REVIEW_MERGE_OUTCOME=unknown'
exit 0

This is one immediate squash-merge compare-and-set: exactly one merge PUT, with no gh pr merge, queue/auto state, admin bypass, head substitution, alternate merge method, fallback or mutation retry. A confirmed merged: true response completes the attempt. Any unconfirmed result permits only the one read-only PR GET shown above. Report merged, open or unknown from that evidence; a merged reconciliation is valid only when its PR head is the exact reviewedHead. On mismatch, unsupported API, permission, checks, ruleset, queue or transport failure, leave the App approval intact and do not attempt another merge. Never use --admin or --auto.

GitHub exposes a head SHA compare-and-set but no base-ref compare-and-set for this merge request. The final complete-identity read is a freshness check, not an atomic base guard; the current small live-state design accepts that narrow read-to-merge retarget race instead of adding a queue or disabling local merge.

Recovery and reporting

Webhook and Inbox delivery are at-least-once, so duplicate run messages are possible. Review the latest live PR state rather than trying to elect one exclusive run. A run's App publication remains idempotent only for the same event and body; an unresolved App write is reconciled by its hidden run marker.

Always remove every known clean, agent-owned detached review worktree and branch-attached repair worktree through normal git worktree remove. Never force-remove an unknown or dirty path; report it for recovery instead.

Report the reviewed head, verification, repairs, App review action and merge result, or one concrete human action. Chat is coordination only: do not copy the GitHub verdict into a second canonical comment/status/receipt protocol.