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

Add controller-owned work allocator to prevent duplicate LLM work on the same issue or PR #600

New Issue
Closed
opened 2026-07-09 16:05:15 -05:00 by jcwalker3 · 6 comments
jcwalker3 commented 2026-07-09 16:05:15 -05:00
Owner
Copy Link
Copy Source

Context

Part of the LLM coordination failure series (sessions stepping on each other). This is a focused implementation issue, not an umbrella.

Problem

Multiple LLM sessions can independently select the same issue or PR and start author/reviewer/merger work before discovering active leases, terminal locks, or already-in-progress sessions. This causes wasted validation, blocked formal decisions, and workflow contention.

Required behavior

  • Add a canonical "next work item" allocator tool.
  • The allocator must inspect open PRs, issues, active leases, terminal locks, labels, reviewer/merger blockers, and stale sessions before returning work.
  • LLMs should not manually choose a PR/issue when using the standard workflow.
  • The allocator must return exactly one of:
    • assigned_work
    • wait
    • blocked_by_terminal_path
    • blocked_by_active_lease
    • needs_controller
    • no_safe_work
  • The allocator must reserve the selected item atomically before returning it.

Acceptance criteria

  1. Two concurrent sessions cannot both receive the same PR/issue as assigned work.
  2. Assignment includes role, repo, issue/PR number, pinned head SHA if applicable, lease/comment ID, expiry, and next valid command.
  3. If #332 or another terminal lock blocks review work, allocator routes to the terminal PR first instead of assigning downstream PRs.
  4. Tests cover two simultaneous reviewers trying to claim the same PR.
  5. Tests cover stale prompt references to old lease IDs.
  6. Tests cover controller-targeted override behavior.

Implementation notes

  • Work can proceed independently of sibling coordination issues, but allocator will eventually consume lease/label/terminal-lock APIs from related work.
  • Fail closed: never invent safe work when state is ambiguous.
## Context Part of the LLM coordination failure series (sessions stepping on each other). This is a focused implementation issue, not an umbrella. ## Problem Multiple LLM sessions can independently select the same issue or PR and start author/reviewer/merger work before discovering active leases, terminal locks, or already-in-progress sessions. This causes wasted validation, blocked formal decisions, and workflow contention. ## Required behavior * Add a canonical "next work item" allocator tool. * The allocator must inspect open PRs, issues, active leases, terminal locks, labels, reviewer/merger blockers, and stale sessions before returning work. * LLMs should not manually choose a PR/issue when using the standard workflow. * The allocator must return exactly one of: * `assigned_work` * `wait` * `blocked_by_terminal_path` * `blocked_by_active_lease` * `needs_controller` * `no_safe_work` * The allocator must reserve the selected item atomically before returning it. ## Acceptance criteria 1. Two concurrent sessions cannot both receive the same PR/issue as assigned work. 2. Assignment includes role, repo, issue/PR number, pinned head SHA if applicable, lease/comment ID, expiry, and next valid command. 3. If #332 or another terminal lock blocks review work, allocator routes to the terminal PR first instead of assigning downstream PRs. 4. Tests cover two simultaneous reviewers trying to claim the same PR. 5. Tests cover stale prompt references to old lease IDs. 6. Tests cover controller-targeted override behavior. ## Implementation notes * Work can proceed independently of sibling coordination issues, but allocator will eventually consume lease/label/terminal-lock APIs from related work. * Fail closed: never invent safe work when state is ambiguous.
jcwalker3 commented 2026-07-09 16:08:08 -05:00
Author
Owner
Copy Link
Copy Source

LLM coordination series (independent implementation issues)

Not an umbrella — each issue can be claimed and shipped independently:

# Focus
#600 Controller-owned work allocator (this issue)
#601 First-class lease adopt/release/expire/abandon
#602 Terminal-lock checks at start of reviewer workflow
#603 Lifecycle labels for ownership/process visibility
#604 Shared anti-stomp preflight before mutations
#605 MCP menu/dashboard for queue, leases, next safe action

Related pre-existing: #599 (foreign lease handoff path).

## LLM coordination series (independent implementation issues) Not an umbrella — each issue can be claimed and shipped independently: | # | Focus | |---|--------| | #600 | Controller-owned work allocator (this issue) | | #601 | First-class lease adopt/release/expire/abandon | | #602 | Terminal-lock checks at start of reviewer workflow | | #603 | Lifecycle labels for ownership/process visibility | | #604 | Shared anti-stomp preflight before mutations | | #605 | MCP menu/dashboard for queue, leases, next safe action | Related pre-existing: #599 (foreign lease handoff path).
jcwalker3 commented 2026-07-09 18:33:07 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: ready for independent implementation — design clarified (MCP allocator is the authority)
WHO_IS_NEXT: author
NEXT_ACTION: implement MCP-native allocation tools; do not implement a separate human/LLM controller role
NEXT_PROMPT:

Implement #600 on Scaled-Tech-Consulting/Gitea-Tools: Gitea MCP tool is the allocation authority. Add gitea_allocate_next_work, gitea_get_assignment, gitea_heartbeat_assignment, gitea_release_assignment, gitea_complete_assignment, gitea_reconcile_assignments, gitea_list_live_allocations. LLM workers must not self-select work. Atomic reserve before return; WAIT if no safe work. SQLite MVP / Postgres preferred for coordination only; Gitea remains durable record; Sentry observes. Mutation tools require valid assignment.

WHAT_HAPPENED: Design clarification added to #600 superseding any framing of a separate human-only or LLM-only controller role.
WHY: Allocation must live in the Gitea MCP control plane so concurrent sessions cannot stomp by self-selecting issues/PRs.
RELATED_PRS: none yet
BLOCKERS: none
VALIDATION: labels updated to include control-plane, database, mcp-menu; clarification recorded on issue thread
LAST_UPDATED_BY: jcwalker3 (prgs-author)

Design clarification (authoritative for #600)

Clarification

The allocator should not be a separate human-only or LLM-only controller role. The Gitea MCP tool itself should become the allocation authority.

Required design — first-class Gitea MCP allocation tools

  • gitea_allocate_next_work
  • gitea_get_assignment
  • gitea_heartbeat_assignment
  • gitea_release_assignment
  • gitea_complete_assignment
  • gitea_reconcile_assignments
  • gitea_list_live_allocations

Worker rules:

  • LLM workers must not self-select issues or PRs.
  • Every worker starts by asking the Gitea MCP allocator for exactly one safe assignment.
  • The allocator must atomically reserve work before returning it.
  • The allocator must return WAIT if no safe work exists.

Storage model

  • Gitea MCP tool is the authority/API.
  • Gitea issues, PRs, comments, and labels remain the durable visible record.
  • A small control-plane storage backend may be used internally for atomic allocation:
    • SQLite acceptable for single-process MVP.
    • Postgres preferred for real server / Proxmox / multiple concurrent LLM sessions.
  • The DB must not replace Gitea as the durable workflow record.
  • The DB coordinates; Gitea records; Sentry observes.

Allocator must inspect

  • open PRs
  • open issues
  • labels/status
  • active leases
  • current assignments
  • stale sessions
  • terminal-review / #332 lock state
  • current-head REQUEST_CHANGES
  • stale approvals
  • contested or contaminated approvals
  • mergeability
  • linked Sentry incidents
  • repo/org scope

Required routing behavior

  • Current-head REQUEST_CHANGES routes to author.
  • Stale approval routes to reviewer.
  • Clean current-head approval routes to merger.
  • Contested/contaminated approval routes to diagnosis/reconciler.
  • Active foreign lease returns WAIT or owner-resume.
  • Terminal-review lock routes to terminal-path resolution before unrelated review work.
  • Locked/in-progress issues are not assigned to another worker.
  • Merged/closed PRs are never assigned.
  • Two concurrent LLMs cannot receive the same issue or PR.

Acceptance criteria (updated)

  1. Four concurrent LLM sessions calling gitea_allocate_next_work(apply=true) cannot receive the same assignment.
  2. Allocation and lease creation happen atomically.
  3. Every assignment includes role, issue/PR number, expected head SHA if applicable, lease ID, expiry, allowed actions, forbidden actions, and ready-to-run prompt.
  4. Worker mutation tools require a valid allocator assignment or sanctioned override.
  5. Gitea labels/comments mirror allocator state so humans can see ownership.
  6. Heartbeats update allocator state without comment spam.
  7. Reconciler can detect and clean expired/abandoned assignments through sanctioned tooling.
  8. Tests cover duplicate PR selection, duplicate issue selection, active lease, stale lease, #332 terminal lock, stale approval, current-head REQUEST_CHANGES, contaminated approval, and merge-ready approval.
  9. Documentation states: no LLM self-selects work; all work starts with the Gitea MCP allocator.
  10. Sentry incident bridge (#607) can create allocator-visible work items, but cannot bypass allocation rules.

Related issues

  • #601 leases, #602 terminal-lock early check, #603 lifecycle labels, #604 anti-stomp preflight, #605 dashboard, #606 Sentry observability, #607 Sentry-to-Gitea bridge
  • Supersedes original "needs_controller" as a primary happy-path outcome for normal queue work; controller/override remains only for sanctioned exceptions, not day-to-day selection.
## Canonical Issue State STATE: ready for independent implementation — design clarified (MCP allocator is the authority) WHO_IS_NEXT: author NEXT_ACTION: implement MCP-native allocation tools; do not implement a separate human/LLM controller role NEXT_PROMPT: ```text Implement #600 on Scaled-Tech-Consulting/Gitea-Tools: Gitea MCP tool is the allocation authority. Add gitea_allocate_next_work, gitea_get_assignment, gitea_heartbeat_assignment, gitea_release_assignment, gitea_complete_assignment, gitea_reconcile_assignments, gitea_list_live_allocations. LLM workers must not self-select work. Atomic reserve before return; WAIT if no safe work. SQLite MVP / Postgres preferred for coordination only; Gitea remains durable record; Sentry observes. Mutation tools require valid assignment. ``` WHAT_HAPPENED: Design clarification added to #600 superseding any framing of a separate human-only or LLM-only controller role. WHY: Allocation must live in the Gitea MCP control plane so concurrent sessions cannot stomp by self-selecting issues/PRs. RELATED_PRS: none yet BLOCKERS: none VALIDATION: labels updated to include control-plane, database, mcp-menu; clarification recorded on issue thread LAST_UPDATED_BY: jcwalker3 (prgs-author) --- ## Design clarification (authoritative for #600) ### Clarification The allocator should **not** be a separate human-only or LLM-only controller role. **The Gitea MCP tool itself should become the allocation authority.** ### Required design — first-class Gitea MCP allocation tools * `gitea_allocate_next_work` * `gitea_get_assignment` * `gitea_heartbeat_assignment` * `gitea_release_assignment` * `gitea_complete_assignment` * `gitea_reconcile_assignments` * `gitea_list_live_allocations` Worker rules: * LLM workers must **not** self-select issues or PRs. * Every worker starts by asking the Gitea MCP allocator for **exactly one** safe assignment. * The allocator must **atomically reserve** work before returning it. * The allocator must return **WAIT** if no safe work exists. ### Storage model * Gitea MCP tool is the authority/API. * Gitea issues, PRs, comments, and labels remain the **durable visible record**. * A small control-plane storage backend may be used **internally** for atomic allocation: * SQLite acceptable for single-process MVP. * Postgres preferred for real server / Proxmox / multiple concurrent LLM sessions. * The DB must **not** replace Gitea as the durable workflow record. * The DB coordinates; Gitea records; Sentry observes. ### Allocator must inspect * open PRs * open issues * labels/status * active leases * current assignments * stale sessions * terminal-review / #332 lock state * current-head REQUEST_CHANGES * stale approvals * contested or contaminated approvals * mergeability * linked Sentry incidents * repo/org scope ### Required routing behavior * Current-head REQUEST_CHANGES routes to **author**. * Stale approval routes to **reviewer**. * Clean current-head approval routes to **merger**. * Contested/contaminated approval routes to **diagnosis/reconciler**. * Active foreign lease returns **WAIT** or **owner-resume**. * Terminal-review lock routes to **terminal-path resolution** before unrelated review work. * Locked/in-progress issues are not assigned to another worker. * Merged/closed PRs are never assigned. * Two concurrent LLMs cannot receive the same issue or PR. ### Acceptance criteria (updated) 1. Four concurrent LLM sessions calling `gitea_allocate_next_work(apply=true)` cannot receive the same assignment. 2. Allocation and lease creation happen atomically. 3. Every assignment includes role, issue/PR number, expected head SHA if applicable, lease ID, expiry, allowed actions, forbidden actions, and ready-to-run prompt. 4. Worker mutation tools require a valid allocator assignment or sanctioned override. 5. Gitea labels/comments mirror allocator state so humans can see ownership. 6. Heartbeats update allocator state without comment spam. 7. Reconciler can detect and clean expired/abandoned assignments through sanctioned tooling. 8. Tests cover duplicate PR selection, duplicate issue selection, active lease, stale lease, #332 terminal lock, stale approval, current-head REQUEST_CHANGES, contaminated approval, and merge-ready approval. 9. Documentation states: no LLM self-selects work; all work starts with the Gitea MCP allocator. 10. Sentry incident bridge (#607) can create allocator-visible work items, but cannot bypass allocation rules. ### Related issues * #601 leases, #602 terminal-lock early check, #603 lifecycle labels, #604 anti-stomp preflight, #605 dashboard, #606 Sentry observability, #607 Sentry-to-Gitea bridge * Supersedes original "needs_controller" as a primary happy-path outcome for normal queue work; controller/override remains only for sanctioned exceptions, not day-to-day selection.
jcwalker3 added mcp-menucontrol-planedatabase and removed workflow-hardening labels 2026-07-09 18:37:27 -05:00
sysadmin commented 2026-07-09 21:20:24 -05:00
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: open; architecture-aligned after ADR land; ready for design stubs only until #613 substrate ships
WHO_IS_NEXT: author
NEXT_ACTION: Wait for or implement after #613; do not claim #600 complete without DB-backed assign+lease
NEXT_PROMPT:

Work #600 on prgs Scaled-Tech-Consulting/Gitea-Tools only after #613 DB substrate is available for real assign+lease.
Canonical ADR: docs/architecture/mcp-allocator-control-plane-observability-adr.md (PR #614 merged, 08c3488d7c35ba27efcd5119514aeeac37b657f7).
Hard rules: gitea_allocate_next_work is allocator authority; no LLM self-selection; no implementation on file locks/comment-only leases alone; mutation tools require valid allocator assignment/lease from control-plane DB; atomic assign+lease in one transaction; routes RC→author, stale approval→reviewer, clean approval+mergeable→merger.

WHAT_HAPPENED: PR #614 merged the allocator/control-plane/observability ADR. This comment records #600 as dependent on #613 and restates allocator authority rules from the ADR.
WHY: #600 body predated the hard #613 dependency and could be read as implementable on existing comment/file locks alone — ADR forbids that as completion.
RELATED_PRS: #614 (merged, merge_commit_sha=08c3488d7c35ba27efcd5119514aeeac37b657f7); ADR docs/architecture/mcp-allocator-control-plane-observability-adr.md; depends on #613; feeds #612
BLOCKERS: Hard dependency on #613 control-plane DB (atomic assignment+lease). Unblock condition: #613 merged to master with assign+lease transactions available. Partial previews allowed only without claiming allocator complete.
VALIDATION: gitea_view_pr #614 closed+merged at 08c3488d7c35ba27efcd5119514aeeac37b657f7; prgs/master contains merge commit; ADR path on master
LAST_UPDATED_BY: sysadmin (prgs-reconciler)

Global architecture statement

DB coordinates, Gitea records, Sentry/GlitchTip observe; the bridge is the only path that turns observations into Gitea work.

Dependency

#613 (hard)  →  #600 allocator API  →  #612 bridge (multi-worker feed)

Hard decisions for #600

  1. MCP tool is the allocator authority — workers call gitea_allocate_next_work (with apply=true only when taking work).
  2. No LLM self-selection under the standard multi-LLM workflow.
  3. No implementation on file locks alone is acceptable as “allocator complete.”
  4. Mutation tools require a valid allocator assignment/lease from the control-plane DB.
  5. Assignment+lease must be one DB transaction; concurrent sessions never get the same issue/PR.
  6. Routing per ADR: current-head REQUEST_CHANGES → author; stale approval → reviewer; clean approval + mergeable → merger; foreign lease → WAIT/owner-resume; terminal lock → resolve first; merged/closed never assigned.

Gitea comments/labels may mirror assignment for humans; they are not the sole lock source.

## Canonical Issue State STATE: open; architecture-aligned after ADR land; ready for design stubs only until #613 substrate ships WHO_IS_NEXT: author NEXT_ACTION: Wait for or implement after #613; do not claim #600 complete without DB-backed assign+lease NEXT_PROMPT: ```text Work #600 on prgs Scaled-Tech-Consulting/Gitea-Tools only after #613 DB substrate is available for real assign+lease. Canonical ADR: docs/architecture/mcp-allocator-control-plane-observability-adr.md (PR #614 merged, 08c3488d7c35ba27efcd5119514aeeac37b657f7). Hard rules: gitea_allocate_next_work is allocator authority; no LLM self-selection; no implementation on file locks/comment-only leases alone; mutation tools require valid allocator assignment/lease from control-plane DB; atomic assign+lease in one transaction; routes RC→author, stale approval→reviewer, clean approval+mergeable→merger. ``` WHAT_HAPPENED: PR #614 merged the allocator/control-plane/observability ADR. This comment records #600 as dependent on #613 and restates allocator authority rules from the ADR. WHY: #600 body predated the hard #613 dependency and could be read as implementable on existing comment/file locks alone — ADR forbids that as completion. RELATED_PRS: #614 (merged, merge_commit_sha=08c3488d7c35ba27efcd5119514aeeac37b657f7); ADR docs/architecture/mcp-allocator-control-plane-observability-adr.md; depends on #613; feeds #612 BLOCKERS: Hard dependency on #613 control-plane DB (atomic assignment+lease). Unblock condition: #613 merged to master with assign+lease transactions available. Partial previews allowed only without claiming allocator complete. VALIDATION: gitea_view_pr #614 closed+merged at 08c3488d7c35ba27efcd5119514aeeac37b657f7; prgs/master contains merge commit; ADR path on master LAST_UPDATED_BY: sysadmin (prgs-reconciler) ### Global architecture statement > **DB coordinates, Gitea records, Sentry/GlitchTip observe; the bridge is the only path that turns observations into Gitea work.** ### Dependency ```text #613 (hard) → #600 allocator API → #612 bridge (multi-worker feed) ``` ### Hard decisions for #600 1. **MCP tool is the allocator authority** — workers call `gitea_allocate_next_work` (with `apply=true` only when taking work). 2. **No LLM self-selection** under the standard multi-LLM workflow. 3. **No implementation on file locks alone** is acceptable as “allocator complete.” 4. **Mutation tools require a valid allocator assignment/lease** from the control-plane DB. 5. Assignment+lease must be **one DB transaction**; concurrent sessions never get the same issue/PR. 6. Routing per ADR: current-head REQUEST_CHANGES → author; stale approval → reviewer; clean approval + mergeable → merger; foreign lease → WAIT/owner-resume; terminal lock → resolve first; merged/closed never assigned. Gitea comments/labels may mirror assignment for humans; they are **not** the sole lock source.
jcwalker3 added status:in-progress and removed status:ready labels 2026-07-10 01:52:47 -05:00
jcwalker3 commented 2026-07-10 01:52:47 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #600 - branch: feat/issue-600-controller-allocator-api - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 added status:pr-open and removed status:in-progress labels 2026-07-10 01:54:33 -05:00
sysadmin reopened this issue 2026-07-10 08:36:48 -05:00
sysadmin commented 2026-07-10 09:20:51 -05:00
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: open — #600 allocator API is on master; issue-close is pending an author session
WHO_IS_NEXT: author
NEXT_ACTION: Close issue #600 via prgs-author; prgs-reconciler has no gitea.issue.close permission and does not reopen or close issues.
NEXT_PROMPT:

Close issue #600 on prgs Scaled-Tech-Consulting/Gitea-Tools. The controller-owned allocator API (gitea_allocate_next_work) landed on master via PR #622 (merge f20c8436aacdaea6ba2448764b43ef05e02d427b; body cited "Closes #600"). Gitea keyword auto-close did not fire, so the issue is still open in a fully-landed state. No further implementation is needed. Also drop the stale status:pr-open label through the label-management path.

WHAT_HAPPENED: PR #622 landed #600 on master; the "Closes #600" keyword did not auto-close the issue, leaving it open. The prior claim heartbeat (comment 9318) is moot because its branch merged via PR #622. Reconciler flagged the stale status:pr-open label but did not strip it, to avoid dropping org-scoped labels.
WHY: The merge auto-close missed; closing requires an author profile. Reconciler flags rather than forces (no permission; not reopening).
RELATED_PRS: #622 (closed, merge f20c8436aa); depends on #613 / PR #619 (10228e1c06); feeds #612 / PR #623 (ab1c2d7973)
BLOCKERS: prgs-reconciler lacks gitea.issue.close — an author session must close #600.
VALIDATION: gitea_view_pr #622 state=closed with merge result f20c843; gitea_view_issue #600 state=open; prgs/master head ab1c2d7973 contains f20c843. Raw Sentry/GlitchTip incidents are non-assignable; only issue/pr kinds are allocatable.
LAST_UPDATED_BY: sysadmin (prgs-reconciler)

[THREAD STATE LEDGER]

What is true now

  • server-side decision state: PR #622 is closed with a merge result recorded on master; issue #600 state = open.
  • local verdict/state: reconciler read-only assessment complete; #600 implementation is on master and issue-close is pending.
  • merge result: merge performed for PR #622 at f20c8436aacdaea6ba2448764b43ef05e02d427b; Gitea auto-close keyword did not fire.
  • prgs/master head: ab1c2d7973 (contains f20c843).

What changed

  • Reconciler posted this ledger only; reconciler performed no state change on issue #600.
  • Stale label status:pr-open flagged for the label-management path (org-scoped type:feature / workflow-hardening cannot be re-resolved by name in the reconciler set-labels tool, so a replace-set would drop them — not performed).

What is blocked

  • blocker classification: permission/capability blocker
  • required action: close issue #600 through prgs-author (gitea.issue.close).

Who/what acts next

  • next actor: prgs-author
  • required action: close #600 (implementation already on master) and drop the stale status:pr-open label.
  • do not do: do not reopen #600 / #612 / #613; do not merge anything; do not re-run implementation; do not assign raw Sentry/GlitchTip incidents as work items.

Chain #613 → #600 → #612 is fully landed on master (10228e1 → f20c843 → ab1c2d7). Raw incidents attach only through incident_links; Gitea issues remain the durable work system.

## Canonical Issue State STATE: open — #600 allocator API is on master; issue-close is pending an author session WHO_IS_NEXT: author NEXT_ACTION: Close issue #600 via prgs-author; prgs-reconciler has no gitea.issue.close permission and does not reopen or close issues. NEXT_PROMPT: ```text Close issue #600 on prgs Scaled-Tech-Consulting/Gitea-Tools. The controller-owned allocator API (gitea_allocate_next_work) landed on master via PR #622 (merge f20c8436aacdaea6ba2448764b43ef05e02d427b; body cited "Closes #600"). Gitea keyword auto-close did not fire, so the issue is still open in a fully-landed state. No further implementation is needed. Also drop the stale status:pr-open label through the label-management path. ``` WHAT_HAPPENED: PR #622 landed #600 on master; the "Closes #600" keyword did not auto-close the issue, leaving it open. The prior claim heartbeat (comment 9318) is moot because its branch merged via PR #622. Reconciler flagged the stale status:pr-open label but did not strip it, to avoid dropping org-scoped labels. WHY: The merge auto-close missed; closing requires an author profile. Reconciler flags rather than forces (no permission; not reopening). RELATED_PRS: #622 (closed, merge f20c8436aacdaea6ba2448764b43ef05e02d427b); depends on #613 / PR #619 (10228e1c068ade36d08e696b7473bcf0a39d0c0d); feeds #612 / PR #623 (ab1c2d797357614fccf4c94bd1ef36fd2e9f8c70) BLOCKERS: prgs-reconciler lacks gitea.issue.close — an author session must close #600. VALIDATION: gitea_view_pr #622 state=closed with merge result f20c843; gitea_view_issue #600 state=open; prgs/master head ab1c2d797357614fccf4c94bd1ef36fd2e9f8c70 contains f20c843. Raw Sentry/GlitchTip incidents are non-assignable; only issue/pr kinds are allocatable. LAST_UPDATED_BY: sysadmin (prgs-reconciler) [THREAD STATE LEDGER] ### What is true now - server-side decision state: PR #622 is closed with a merge result recorded on master; issue #600 state = open. - local verdict/state: reconciler read-only assessment complete; #600 implementation is on master and issue-close is pending. - merge result: merge performed for PR #622 at f20c8436aacdaea6ba2448764b43ef05e02d427b; Gitea auto-close keyword did not fire. - prgs/master head: ab1c2d797357614fccf4c94bd1ef36fd2e9f8c70 (contains f20c843). ### What changed - Reconciler posted this ledger only; reconciler performed no state change on issue #600. - Stale label status:pr-open flagged for the label-management path (org-scoped type:feature / workflow-hardening cannot be re-resolved by name in the reconciler set-labels tool, so a replace-set would drop them — not performed). ### What is blocked - blocker classification: permission/capability blocker - required action: close issue #600 through prgs-author (gitea.issue.close). ### Who/what acts next - next actor: prgs-author - required action: close #600 (implementation already on master) and drop the stale status:pr-open label. - do not do: do not reopen #600 / #612 / #613; do not merge anything; do not re-run implementation; do not assign raw Sentry/GlitchTip incidents as work items. Chain #613 → #600 → #612 is fully landed on master (10228e1 → f20c843 → ab1c2d7). Raw incidents attach only through incident_links; Gitea issues remain the durable work system.
jcwalker3 removed the status:pr-open label 2026-07-10 09:40:27 -05:00
jcwalker3 commented 2026-07-10 09:40:47 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE:
closed
WHO_IS_NEXT:
user
NEXT_ACTION:
no further author work on #600; chain #613 → #600 → #612 is landed on master; use allocator and bridge via normal workflow only
NEXT_PROMPT:

No implementation work remains for issue #600. Master includes PR #622 merge f20c8436aacdaea6ba2448764b43ef05e02d427b (allocator) after #613 substrate 10228e1 and before #612 bridge ab1c2d7. Do not reopen #600/#612/#613. Do not assign raw Sentry/GlitchTip incidents as work items; Gitea issues remain the durable work system.

WHAT_HAPPENED:
Author post-merge reconciliation closed issue #600 after PR #622 landed on master and auto-close did not fire; removed stale status:pr-open from #600, #612, and #613 while preserving all non-status labels.
WHY:
PR #622 body included Closes #600 and merge commit f20c843 is on prgs/master, but issue #600 remained open with stale status:pr-open; reconciler could not safely rewrite full label sets due to label-name resolution limits on colon-prefixed labels when using replace-all with incomplete label pages.
RELATED_PRS:
#622 (implements #600, merge f20c843); #619 (#613, merge 10228e1); #623 (#612, merge ab1c2d7)
BLOCKERS:
none remaining for this chain; label cleanup completed via surgical DELETE of status:pr-open only (id 100), not a lossy full replace
VALIDATION:
live prgs/master contains 10228e1, f20c843, ab1c2d7; PR #619/#622/#623 closed with matching merge SHAs; issue #600 state closed; labels after cleanup omit status:pr-open and retain allocator/control-plane/type:feature (and peers on #612/#613)
LAST_UPDATED_BY:
jcwalker3 (prgs-author)

Post-merge reconciliation (#600)

  • PR #622 merged at f20c8436aacdaea6ba2448764b43ef05e02d427b — #600 implementation is on master.
  • Issue #600 closed manually because auto-close from Closes #600 did not fire.
  • Issues #613 and #612 were already closed (PR #619 / #623).
  • Stale status:pr-open removed from #600, #612, and #613 by surgical label DELETE (label id 100 only). Non-status labels preserved (including type:feature, workflow-hardening where present).
  • No code changes, no new PR, no merge performed in this reconciliation session.
  • Raw monitoring incidents remain non-assignable; Gitea issues remain the durable work system.
## Canonical Issue State STATE: closed WHO_IS_NEXT: user NEXT_ACTION: no further author work on #600; chain #613 → #600 → #612 is landed on master; use allocator and bridge via normal workflow only NEXT_PROMPT: ```text No implementation work remains for issue #600. Master includes PR #622 merge f20c8436aacdaea6ba2448764b43ef05e02d427b (allocator) after #613 substrate 10228e1 and before #612 bridge ab1c2d7. Do not reopen #600/#612/#613. Do not assign raw Sentry/GlitchTip incidents as work items; Gitea issues remain the durable work system. ``` WHAT_HAPPENED: Author post-merge reconciliation closed issue #600 after PR #622 landed on master and auto-close did not fire; removed stale status:pr-open from #600, #612, and #613 while preserving all non-status labels. WHY: PR #622 body included Closes #600 and merge commit f20c843 is on prgs/master, but issue #600 remained open with stale status:pr-open; reconciler could not safely rewrite full label sets due to label-name resolution limits on colon-prefixed labels when using replace-all with incomplete label pages. RELATED_PRS: #622 (implements #600, merge f20c843); #619 (#613, merge 10228e1); #623 (#612, merge ab1c2d7) BLOCKERS: none remaining for this chain; label cleanup completed via surgical DELETE of status:pr-open only (id 100), not a lossy full replace VALIDATION: live prgs/master contains 10228e1, f20c843, ab1c2d7; PR #619/#622/#623 closed with matching merge SHAs; issue #600 state closed; labels after cleanup omit status:pr-open and retain allocator/control-plane/type:feature (and peers on #612/#613) LAST_UPDATED_BY: jcwalker3 (prgs-author) ## Post-merge reconciliation (#600) * PR **#622** merged at `f20c8436aacdaea6ba2448764b43ef05e02d427b` — #600 implementation is on master. * Issue **#600** closed **manually** because auto-close from `Closes #600` did not fire. * Issues **#613** and **#612** were already closed (PR #619 / #623). * Stale **`status:pr-open`** removed from **#600**, **#612**, and **#613** by surgical label DELETE (label id 100 only). Non-status labels preserved (including `type:feature`, `workflow-hardening` where present). * No code changes, no new PR, no merge performed in this reconciliation session. * Raw monitoring incidents remain non-assignable; Gitea issues remain the durable work system.
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 allocator anti-stomp concurrency control-plane database mcp-menu type:feature
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#600