Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Require explicit worktree and cwd proof for PR review validation commands #398

New Issue
Closed
opened 2026-07-07 09:28:52 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-07 09:28:52 -05:00
Owner
Copy Link
Copy Source

Problem:
Reviewer final reports can claim validation ran in the PR review worktree even when the visible command transcript does not prove the command working directory. This creates a risk that tests or diffs were run against master, the main checkout, or a stale worktree while the report claims the PR head was validated.

Observed example:
A PR #376 review/merge report created branches/review-feat-issue-308-reconcile-inventory-pagination and pinned head f5953549aad5e822f14f52d3ea3c6d7990109384. It later claimed targeted and full tests ran in that review worktree. However, the visible commands did not consistently show git -C branches/..., explicit working directory, or pwd proof before validation commands.

Required behavior:
Every PR review validation command must explicitly prove the target worktree path and checked-out SHA immediately before running validation.

Acceptance criteria:

  1. Before any diff/test/compile validation, reviewer must record:

    • pwd or explicit command working directory,
    • git rev-parse HEAD,
    • git status --short --branch,
    • expected PR head SHA.

  2. Validation commands must use one of:

    • git -C <review_worktree> ...,
    • cd <review_worktree> && ... in the same command,
    • tool-provided explicit working directory metadata.

  3. Final report must include exact validation command, cwd/worktree, and observed HEAD SHA.

  4. gitea_dry_run_pr_review or final-report validator rejects reports that claim review-worktree validation without cwd/HEAD proof.

  5. Baseline validation must follow the same rule:

    • baseline worktree path,
    • baseline target SHA,
    • cwd proof,
    • exact baseline validation command,
    • baseline result.

  6. Cleanup claims must include final worktree-list proof or equivalent.

  7. Tests cover:

    • validation command without cwd proof,
    • validation command run from main checkout,
    • validation command with wrong HEAD,
    • baseline validation without baseline cwd proof,
    • fully proof-backed validation report.

  8. Documentation updates the review-merge workflow template.

Non-goals:

  • Do not block valid PRs with complete worktree proof.
  • Do not weaken reviewer identity, author-safety, or merge capability gates.
  • Do not allow inferred shell cwd as proof.
Problem: Reviewer final reports can claim validation ran in the PR review worktree even when the visible command transcript does not prove the command working directory. This creates a risk that tests or diffs were run against `master`, the main checkout, or a stale worktree while the report claims the PR head was validated. Observed example: A PR #376 review/merge report created `branches/review-feat-issue-308-reconcile-inventory-pagination` and pinned head `f5953549aad5e822f14f52d3ea3c6d7990109384`. It later claimed targeted and full tests ran in that review worktree. However, the visible commands did not consistently show `git -C branches/...`, explicit working directory, or `pwd` proof before validation commands. Required behavior: Every PR review validation command must explicitly prove the target worktree path and checked-out SHA immediately before running validation. Acceptance criteria: 1. Before any diff/test/compile validation, reviewer must record: * `pwd` or explicit command working directory, * `git rev-parse HEAD`, * `git status --short --branch`, * expected PR head SHA. 2. Validation commands must use one of: * `git -C <review_worktree> ...`, * `cd <review_worktree> && ...` in the same command, * tool-provided explicit working directory metadata. 3. Final report must include exact validation command, cwd/worktree, and observed HEAD SHA. 4. `gitea_dry_run_pr_review` or final-report validator rejects reports that claim review-worktree validation without cwd/HEAD proof. 5. Baseline validation must follow the same rule: * baseline worktree path, * baseline target SHA, * cwd proof, * exact baseline validation command, * baseline result. 6. Cleanup claims must include final worktree-list proof or equivalent. 7. Tests cover: * validation command without cwd proof, * validation command run from main checkout, * validation command with wrong HEAD, * baseline validation without baseline cwd proof, * fully proof-backed validation report. 8. Documentation updates the review-merge workflow template. Non-goals: * Do not block valid PRs with complete worktree proof. * Do not weaken reviewer identity, author-safety, or merge capability gates. * Do not allow inferred shell cwd as proof.
jcwalker3 added the status:in-progress label 2026-07-07 10:27:07 -05:00
jcwalker3 commented 2026-07-07 10:27:11 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #398 - branch: feat/issue-398-validation-cwd-proof - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
sysadmin removed the status:in-progress label 2026-07-08 02:09:13 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#398