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

Enforce exact issue lock before branch, commit, push, or PR creation #204

New Issue
Closed
opened 2026-07-05 15:23:10 -05:00 by sysadmin · 1 comment
sysadmin commented 2026-07-05 15:23:10 -05:00
Owner
Copy Link
Copy Source

Problem:
Author agents can implement a change without a clean, exact issue binding, then describe the work as tied to an 'equivalent' issue. This breaks durable workflow tracking and allows wall changes to bypass the issue-first process.

Required wall:
Before any branch creation, commit, push, or PR creation, the author workflow must resolve and lock exactly one issue.

Forbidden:

  • 'equivalent issue'
  • 'related issue'
  • 'same as #X'
  • missing issue number
  • reusing an issue already tied to a different open PR unless explicitly approved by the issue body
  • branch names that do not match the locked issue

Acceptance criteria:

  • Add a hard gate requiring selected_issue.number before branch creation.
  • Add a hard gate requiring the branch name to include the locked issue number.
  • Add a hard gate requiring the PR title/body to include Closes #<locked_issue>.
  • Add a test where the agent reports 'Issue #194 / #196 equivalent'; expected result: blocked.
  • Add a test where an issue already has an open PR and the agent tries to reuse it for unrelated work; expected result: blocked.
  • Final handoff must include exactly one selected issue and exactly one opened PR.
Problem: Author agents can implement a change without a clean, exact issue binding, then describe the work as tied to an 'equivalent' issue. This breaks durable workflow tracking and allows wall changes to bypass the issue-first process. Required wall: Before any branch creation, commit, push, or PR creation, the author workflow must resolve and lock exactly one issue. Forbidden: - 'equivalent issue' - 'related issue' - 'same as #X' - missing issue number - reusing an issue already tied to a different open PR unless explicitly approved by the issue body - branch names that do not match the locked issue Acceptance criteria: - Add a hard gate requiring selected_issue.number before branch creation. - Add a hard gate requiring the branch name to include the locked issue number. - Add a hard gate requiring the PR title/body to include Closes #<locked_issue>. - Add a test where the agent reports 'Issue #194 / #196 equivalent'; expected result: blocked. - Add a test where an issue already has an open PR and the agent tries to reuse it for unrelated work; expected result: blocked. - Final handoff must include exactly one selected issue and exactly one opened PR.
jcwalker3 added the status:in-progress label 2026-07-05 15:46:22 -05:00
jcwalker3 commented 2026-07-05 15:46:36 -05:00
Owner
Copy Link
Copy Source

Issue lock (recreation run after PR #205 was closed for invalid provenance).

  • Locked issue: #204 (exactly one)
  • Branch: feat/issue-204-exact-issue-lock-v2 (fresh, to be created off master; old feat/issue-204-exact-issue-lock belongs to closed PR #205 and will not be reused)
  • Base branch: master @ 4dcf8fdfe431b0ffe2131e183ae810aa28777bde
  • Repo/remote: Scaled-Tech-Consulting/Gitea-Tools on prgs
  • Identity/profile: jcwalker3 / prgs-author; capabilities in use: gitea.issue.comment (this claim), gitea.branch.create, gitea.repo.commit, gitea.branch.push, gitea.pr.create — all allowed in the active profile
  • Lock time: before any tracked-file edit, branch creation, or commit for this run (per #204/#208 lock-before-work ordering)
  • Scope: only the #204 exact-issue-lock changes; commit 10d2644 (PR #203 content) is explicitly excluded; not stacked work
  • Plan: implement fresh on the new branch, run py_compile + targeted tests + full suite + git diff --check + secret sweep, open replacement PR with Closes #204, back-link from closed PR #205
Issue lock (recreation run after PR #205 was closed for invalid provenance). - Locked issue: #204 (exactly one) - Branch: `feat/issue-204-exact-issue-lock-v2` (fresh, to be created off `master`; old `feat/issue-204-exact-issue-lock` belongs to closed PR #205 and will not be reused) - Base branch: `master` @ `4dcf8fdfe431b0ffe2131e183ae810aa28777bde` - Repo/remote: `Scaled-Tech-Consulting/Gitea-Tools` on `prgs` - Identity/profile: `jcwalker3 / prgs-author`; capabilities in use: `gitea.issue.comment` (this claim), `gitea.branch.create`, `gitea.repo.commit`, `gitea.branch.push`, `gitea.pr.create` — all allowed in the active profile - Lock time: before any tracked-file edit, branch creation, or commit for this run (per #204/#208 lock-before-work ordering) - Scope: only the #204 exact-issue-lock changes; commit `10d2644` (PR #203 content) is explicitly excluded; not stacked work - Plan: implement fresh on the new branch, run py_compile + targeted tests + full suite + `git diff --check` + secret sweep, open replacement PR with `Closes #204`, back-link from closed PR #205
sysadmin removed the status:in-progress label 2026-07-05 19:28:16 -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
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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