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

Enforce autonomous canonical handoffs and dependency-aware concurrent task orchestration #628

New Issue
Open
opened 2026-07-10 11:57:35 -05:00 by jcwalker3 · 3 comments
jcwalker3 commented 2026-07-10 11:57:35 -05:00
Owner
Copy Link
Copy Source

Problem

The workflow still depends on humans to copy ready-to-paste prompts, transfer reports between LLM sessions, restate scope, choose the next role, watch dependencies, and resume blocked work.

Even when stages produce detailed handoffs, those artifacts often land only in chat-facing reports. The next worker does not automatically retrieve a validated canonical handoff through the task router/allocator. Concurrent workers can still collide, and blocked tasks can stall without structured dependency tracking or automatic resumption.

Evidence lifecycle (example only, not sole scope): Issue #601 / PR #625 — author handoff → reviewer approval → merger transition → merge → remaining reconciliation → reconciliation blocked by label-pagination defect (#627) → need for durable defect linking and later automatic resumption without user babysitting.

Impact

  • Normal multi-stage work requires continuous user redirection.
  • Full evidence dumps pollute user-facing final responses.
  • Concurrent LLM workers risk duplicate ownership of the same exclusive task unit.
  • Blocked work is remembered in prose, not as durable dependency state.
  • Dependency satisfaction does not reliably requeue waiting work.
  • Tooling defects discovered mid-task are not systematically escalated, linked, and later auto-resumed.

Desired end state

An autonomous, model-agnostic workflow that:

  1. automatically stores complete validated canonical handoffs in Gitea;
  2. automatically retrieves them at worker startup via router/allocator;
  3. coordinates concurrent workers with exclusive leases;
  4. represents dependencies as durable structured state;
  5. blocks and resumes tasks automatically when dependencies change;
  6. keeps user-facing responses brief;
  7. requests user attention only at a defined boundary.

Ready-to-paste prompts remain allowed for debugging, recovery, one-off intake, or unsupported manual transitions — not as the normal continuation mechanism.

User-facing response policy

Visible final responses should normally contain only:

  • short statement of what happened;
  • resulting task state;
  • next role or automatic next step;
  • blockers requiring user attention, if any;
  • links/identifiers for issue, PR, or durable defect created.

Full evidence, decisions, mutation ledger, dependencies, and continuation instructions belong in the canonical Gitea record only.

Umbrella ownership (do not duplicate components)

This is an integration umbrella. Implement by wiring and extending existing components; do not re-own sibling issues wholesale.

Component / related issues

Area Issues
Handoff enforcement through controller closure #626 (primary handoff sub-scope)
CTH / next-action / validators / controller acceptance foundations #494, #495, #496, #500, #501, #505, #507 (closed)
Allocator / atomic assignment #600, #613 (closed; extend)
Leases lifecycle #601 (closed; extend)
Lifecycle labels visibility #603 (open)
Queue dashboard / next safe action #605 (open)
Anti-stomp preflight #604 (open)
Label-pagination defect (example tooling blocker) #627
Stale runtime / namespace health #610, #615, #584

Scope

1. Canonical issue specification (durable task definition)

Issue body remains the authoritative task definition:

  • problem, impact, scope, non-goals;
  • implementation investigation;
  • acceptance criteria;
  • safety/architecture constraints;
  • dependencies;
  • related issues/PRs.

Stage responses must not recopy the full specification.

2. Canonical stage handoff (automatic store)

Every non-terminal stage automatically stores a validated handoff with at least:

  • schema version;
  • repository;
  • issue;
  • PR when applicable;
  • authoritative specification reference;
  • current workflow state;
  • acting role;
  • acting identity and profile;
  • current head/base/merge/deployment identifiers;
  • completed work;
  • validation and evidence;
  • decisions;
  • rationale;
  • acceptance-criteria status;
  • mutation ledger;
  • unresolved items;
  • blockers;
  • dependencies;
  • lease and assignment state;
  • responsible next role;
  • exact next action;
  • prohibited actions;
  • machine-retrievable continuation instructions;
  • timestamp.

Continuation instructions may internally contain a complete prompt, but the workflow must deliver it to the next actor automatically.

3. Automatic handoff retrieval

At startup, a worker requests/receives the next assigned task and:

  1. identifies role, profile, namespace, capabilities;
  2. retrieves assigned issue/PR;
  3. retrieves latest valid canonical handoff;
  4. verifies against live Gitea and Git state;
  5. detects stale or contradictory state;
  6. binds correct isolated worktree;
  7. acquires exclusive task lease;
  8. begins the stage without external chat context.

Workers must not depend on the previous LLM’s visible final response.

4. Concurrent work and exclusive task units

Multiple LLM instances may work concurrently when independent or dependency paths are clear.

At most one active worker may own the same exclusive task unit:

  • one issue implementation;
  • one PR review at a pinned head;
  • one merge operation;
  • one reconciliation task;
  • one controller decision;
  • one infrastructure recovery task.

Prevent independent simultaneous performance of the same unit.

5. Assignment and lease requirements

Each active assignment must include repository, issue, PR when applicable, operation/stage, pinned head/version, role, session, namespace, worktree, lease owner, lease state, expiry/renewal.

Allocator must enforce:

  • one active owner per exclusive unit;
  • no silent lease stealing;
  • no duplicate author implementation on same issue;
  • no duplicate reviews of same required slot unless explicitly allowed;
  • no merge against unreviewed or changed head;
  • no reconciliation racing active merge;
  • no controller closure while required work remains active.

Different issues/unrelated PRs continue concurrently.

6. Dependency graph (durable structured state)

Represent dependencies explicitly (not prose-only):

  • issue blocked by issue;
  • PR waiting for requested changes;
  • merge waiting for approval;
  • reconciliation waiting for merge;
  • deployment waiting for infrastructure;
  • controller acceptance waiting for validation;
  • task waiting for tooling defect fix/deploy.

Each dependency: source, target, type, blocking condition, completion condition, current state, evidence.

7. Automatic blocking and resumption

Unresolved dependency → automatic blocked/waiting:

  • release/suspend resources that should not remain held;
  • preserve canonical context;
  • record exact blocker and linked dependency;
  • avoid reassigning blocked task;
  • continue unrelated runnable work.

Dependency satisfied → reevaluate dependents, requeue runnable work, revalidate live state before continuing (no stale assumptions).

Examples: requested changes pushed → reviewer runnable; approval at current head → merger runnable; tooling-fix merged + runtime refreshed → blocked reconciliation runnable; infra restored → validation resumes; controller requests more work → author runnable.

8. Runnable task selection

Allocator policy considers state, role requirements, dependency readiness, lease availability, priority, age, repo policy, worker capability, namespace/worktree availability.

Raw monitoring incidents/unclassified observations are not automatically assignable. Only durable classified work items enter the queue.

9. Separate workflow defects

When a worker discovers out-of-scope tooling/process defect:

  1. search existing issues;
  2. create if none exact;
  3. link as dependency if blocking;
  4. store complete defect context on that issue;
  5. move active task to blocked;
  6. continue unrelated work;
  7. auto-resume after completion condition met.

User may see short notice + issue link; no manual defect-prompt transfer under normal operation.

10. User-attention boundary

Request user only for:

  • missing business decision;
  • ambiguous product requirement;
  • non-delegable authorization;
  • destructive/externally consequential consent;
  • unavailable credential/system access;
  • conflicting controller policies;
  • irrecoverable workflow state.

Routine author/reviewer/merger/reconciler/allocator/dependency/retry transitions are automatic.

11. Terminal completion

Terminal only when acceptance criteria satisfied; required review/merge complete; reconciliation/cleanup complete; dependencies resolved; canonical state current; controller acceptance recorded when required.

Terminal handoff shape:

STATE: complete
WHO_IS_NEXT: none
NEXT_ACTION: none
CONTINUATION: none

User-facing response remains brief.

Architecture investigation (authoritative ownership)

Current components to integrate:

Concern Primary owners (current codebase)
Task routing / role role_session_router.py, task_capability_map.py, gitea_resolve_task_capability
Assignment / next work allocator_service.py (allocate_next_work), control-plane assignment APIs
Atomic leases/sessions control_plane_db.py (assign_and_lease), issue_lock_store.py, pr_work_lease.py
Capability / namespace capability resolver, namespace_workspace_binding.py, role_namespace_gate.py
Worktree binding author/reviewer worktree modules, branches-only guards
Issue/PR durable history Gitea issues/PRs/comments/reviews/labels
Workflow labels issue_workflow_labels.py, #603
Canonical comments / CTH canonical_thread_handoff.py, canonical_state_comments.py, canonical_comment_validator.py
Thread-state ledger state_handoff_ledger.py, thread_state_ledger_validator.py
Final reports final_report_validator.py, role final-report schemas
Controller acceptance issue_acceptance_gate.py, #500
Cleanup/reconcile merged_cleanup_reconcile.py, reconciler workflows

Authority model (target)

Authority Owns
Gitea Durable issue/PR history, canonical handoffs/comments, reviews, labels, merge/close
Control-plane DB / allocator Atomic assignment, exclusive leases, session heartbeats, runnable queue coordination
Dependency graph (to add/extend) Structured edges, blocking/completion conditions, auto reevaluation
Canonical handoff store (Gitea + schema) Stage continuation payload for next worker
Capability/namespace gates Next-role eligibility and mutation authorization
Controller gate Terminal acceptance when required

Rule of thumb: DB coordinates concurrency; Gitea records durable truth; handoff schema carries continuation; controller owns final acceptance; allocator delivers work without chat paste.

Where automatic continuation should occur

  1. Stage completion tool path → validate + post canonical handoff + update assignment/dependency state.
  2. Allocator startup path → retrieve assignment + latest handoff + live revalidation + lease bind.
  3. Dependency completion event → reevaluate waiters → enqueue runnable roles.
  4. Worker crash/lease expiry → sanctioned recovery → reassignment without duplicate ownership.
  5. Defect discovery path → create/link issue → block dependent → keep unrelated runnable.

Safety and architectural constraints

  • Fail closed on ambiguous ownership, stale head, or contradictory canonical state.
  • Do not bypass existing capability, role, lease, or controller gates.
  • Do not replace Gitea as durable history.
  • Do not auto-assign raw unclassified monitoring incidents.
  • Do not silently steal leases.
  • Do not treat chat-facing final reports as the system of record.
  • Model-agnostic: any LLM worker with correct profile/namespace can continue from Gitea + assignment only.

Non-goals

  • Do not hard-code Issue #601 or PR #625 behavior as sole scope.
  • Do not require humans to paste reports between roles for normal flow.
  • Do not place project-specific acceptance criteria into generic workflow prompts.
  • Do not re-implement closed foundations (#494–#507, #500, #600, #601, #613) from scratch.
  • Do not solve unrelated namespace/worktree/runtime defects inside this umbrella unless required for orchestration correctness.
  • Do not dump full handoffs into normal user-facing responses.

Acceptance criteria

  1. Every non-terminal stage automatically stores a complete validated canonical handoff.
  2. The next worker automatically retrieves the handoff.
  3. No normal workflow transition requires the user to copy a prompt.
  4. User-facing final responses are brief and do not duplicate the full handoff.
  5. Multiple workers can process independent tasks concurrently.
  6. The same exclusive task unit cannot have multiple active owners.
  7. Assignments are role-, session-, namespace-, worktree-, and head-bound.
  8. Dependencies are represented as durable structured state.
  9. Blocked tasks are excluded from runnable assignment.
  10. Unrelated runnable tasks continue while another task is blocked.
  11. Dependency completion automatically reevaluates waiting tasks.
  12. Resumed tasks revalidate live state before continuing.
  13. Separate workflow defects are automatically linked as dependencies.
  14. The workflow does not create duplicate defect work.
  15. Changed PR heads invalidate stale review and merge eligibility.
  16. A merged task remains non-terminal while required reconciliation remains.
  17. Controller acceptance is enforced when required.
  18. Terminal tasks produce no unnecessary next assignment.
  19. Routine progress requires no user monitoring or redirection.
  20. User intervention is requested only at the defined attention boundary.
  21. Tests cover:
    • automatic author-to-reviewer handoff;
    • reviewer-to-author handoff;
    • reviewer-to-merger handoff;
    • merger-to-reconciler handoff;
    • reconciler-to-controller handoff;
    • controller-to-terminal completion;
    • two independent issues worked concurrently;
    • duplicate assignment rejection;
    • same PR head review collision;
    • changed-head invalidation;
    • dependency blocking;
    • unrelated task progress during a block;
    • automatic dependency resumption;
    • tooling-defect dependency;
    • stale lease recovery;
    • worker crash and reassignment;
    • brief user-facing response;
    • complete canonical backend handoff;
    • operation without external chat history.

Implementation investigation notes

  • Prefer extending allocate_next_work + control-plane assignment to return handoff reference + machine continuation package.
  • Prefer extending final-report and comment validators to require handoff post + brief user-facing separation.
  • Prefer a structured dependency table/index (control-plane and/or durable Gitea-mirrored comments) rather than prose-only blockers.
  • #626 remains the focused handoff-schema/enforcement track; this umbrella owns end-to-end autonomy, concurrency, dependency orchestration, and user-attention policy.
  • Controller triage should establish implementation order across #626, #603, #605, #604, dependency graph, and allocator retrieval wiring.
## Problem The workflow still depends on humans to copy ready-to-paste prompts, transfer reports between LLM sessions, restate scope, choose the next role, watch dependencies, and resume blocked work. Even when stages produce detailed handoffs, those artifacts often land only in chat-facing reports. The next worker does not automatically retrieve a validated canonical handoff through the task router/allocator. Concurrent workers can still collide, and blocked tasks can stall without structured dependency tracking or automatic resumption. Evidence lifecycle (example only, not sole scope): Issue #601 / PR #625 — author handoff → reviewer approval → merger transition → merge → remaining reconciliation → reconciliation blocked by label-pagination defect (#627) → need for durable defect linking and later automatic resumption without user babysitting. ## Impact * Normal multi-stage work requires continuous user redirection. * Full evidence dumps pollute user-facing final responses. * Concurrent LLM workers risk duplicate ownership of the same exclusive task unit. * Blocked work is remembered in prose, not as durable dependency state. * Dependency satisfaction does not reliably requeue waiting work. * Tooling defects discovered mid-task are not systematically escalated, linked, and later auto-resumed. ## Desired end state An autonomous, model-agnostic workflow that: 1. automatically stores complete validated canonical handoffs in Gitea; 2. automatically retrieves them at worker startup via router/allocator; 3. coordinates concurrent workers with exclusive leases; 4. represents dependencies as durable structured state; 5. blocks and resumes tasks automatically when dependencies change; 6. keeps user-facing responses brief; 7. requests user attention only at a defined boundary. Ready-to-paste prompts remain allowed for debugging, recovery, one-off intake, or unsupported manual transitions — **not** as the normal continuation mechanism. ## User-facing response policy Visible final responses should normally contain only: * short statement of what happened; * resulting task state; * next role or automatic next step; * blockers requiring user attention, if any; * links/identifiers for issue, PR, or durable defect created. Full evidence, decisions, mutation ledger, dependencies, and continuation instructions belong in the canonical Gitea record only. ## Umbrella ownership (do not duplicate components) This is an **integration umbrella**. Implement by wiring and extending existing components; do not re-own sibling issues wholesale. ### Component / related issues | Area | Issues | |------|--------| | Handoff enforcement through controller closure | **#626** (primary handoff sub-scope) | | CTH / next-action / validators / controller acceptance foundations | #494, #495, #496, #500, #501, #505, #507 (closed) | | Allocator / atomic assignment | #600, #613 (closed; extend) | | Leases lifecycle | #601 (closed; extend) | | Lifecycle labels visibility | #603 (open) | | Queue dashboard / next safe action | #605 (open) | | Anti-stomp preflight | #604 (open) | | Label-pagination defect (example tooling blocker) | #627 | | Stale runtime / namespace health | #610, #615, #584 | ## Scope ### 1. Canonical issue specification (durable task definition) Issue body remains the authoritative task definition: * problem, impact, scope, non-goals; * implementation investigation; * acceptance criteria; * safety/architecture constraints; * dependencies; * related issues/PRs. Stage responses must not recopy the full specification. ### 2. Canonical stage handoff (automatic store) Every non-terminal stage automatically stores a validated handoff with at least: * schema version; * repository; * issue; * PR when applicable; * authoritative specification reference; * current workflow state; * acting role; * acting identity and profile; * current head/base/merge/deployment identifiers; * completed work; * validation and evidence; * decisions; * rationale; * acceptance-criteria status; * mutation ledger; * unresolved items; * blockers; * dependencies; * lease and assignment state; * responsible next role; * exact next action; * prohibited actions; * machine-retrievable continuation instructions; * timestamp. Continuation instructions may internally contain a complete prompt, but the workflow must deliver it to the next actor automatically. ### 3. Automatic handoff retrieval At startup, a worker requests/receives the next assigned task and: 1. identifies role, profile, namespace, capabilities; 2. retrieves assigned issue/PR; 3. retrieves latest valid canonical handoff; 4. verifies against live Gitea and Git state; 5. detects stale or contradictory state; 6. binds correct isolated worktree; 7. acquires exclusive task lease; 8. begins the stage without external chat context. Workers must not depend on the previous LLM’s visible final response. ### 4. Concurrent work and exclusive task units Multiple LLM instances may work concurrently when independent or dependency paths are clear. At most one active worker may own the same exclusive task unit: * one issue implementation; * one PR review at a pinned head; * one merge operation; * one reconciliation task; * one controller decision; * one infrastructure recovery task. Prevent independent simultaneous performance of the same unit. ### 5. Assignment and lease requirements Each active assignment must include repository, issue, PR when applicable, operation/stage, pinned head/version, role, session, namespace, worktree, lease owner, lease state, expiry/renewal. Allocator must enforce: * one active owner per exclusive unit; * no silent lease stealing; * no duplicate author implementation on same issue; * no duplicate reviews of same required slot unless explicitly allowed; * no merge against unreviewed or changed head; * no reconciliation racing active merge; * no controller closure while required work remains active. Different issues/unrelated PRs continue concurrently. ### 6. Dependency graph (durable structured state) Represent dependencies explicitly (not prose-only): * issue blocked by issue; * PR waiting for requested changes; * merge waiting for approval; * reconciliation waiting for merge; * deployment waiting for infrastructure; * controller acceptance waiting for validation; * task waiting for tooling defect fix/deploy. Each dependency: source, target, type, blocking condition, completion condition, current state, evidence. ### 7. Automatic blocking and resumption Unresolved dependency → automatic blocked/waiting: * release/suspend resources that should not remain held; * preserve canonical context; * record exact blocker and linked dependency; * avoid reassigning blocked task; * continue unrelated runnable work. Dependency satisfied → reevaluate dependents, requeue runnable work, **revalidate live state** before continuing (no stale assumptions). Examples: requested changes pushed → reviewer runnable; approval at current head → merger runnable; tooling-fix merged + runtime refreshed → blocked reconciliation runnable; infra restored → validation resumes; controller requests more work → author runnable. ### 8. Runnable task selection Allocator policy considers state, role requirements, dependency readiness, lease availability, priority, age, repo policy, worker capability, namespace/worktree availability. Raw monitoring incidents/unclassified observations are **not** automatically assignable. Only durable classified work items enter the queue. ### 9. Separate workflow defects When a worker discovers out-of-scope tooling/process defect: 1. search existing issues; 2. create if none exact; 3. link as dependency if blocking; 4. store complete defect context on that issue; 5. move active task to blocked; 6. continue unrelated work; 7. auto-resume after completion condition met. User may see short notice + issue link; no manual defect-prompt transfer under normal operation. ### 10. User-attention boundary Request user only for: * missing business decision; * ambiguous product requirement; * non-delegable authorization; * destructive/externally consequential consent; * unavailable credential/system access; * conflicting controller policies; * irrecoverable workflow state. Routine author/reviewer/merger/reconciler/allocator/dependency/retry transitions are automatic. ### 11. Terminal completion Terminal only when acceptance criteria satisfied; required review/merge complete; reconciliation/cleanup complete; dependencies resolved; canonical state current; controller acceptance recorded when required. Terminal handoff shape: ```text STATE: complete WHO_IS_NEXT: none NEXT_ACTION: none CONTINUATION: none ``` User-facing response remains brief. ## Architecture investigation (authoritative ownership) Current components to integrate: | Concern | Primary owners (current codebase) | |---------|-----------------------------------| | Task routing / role | `role_session_router.py`, `task_capability_map.py`, `gitea_resolve_task_capability` | | Assignment / next work | `allocator_service.py` (`allocate_next_work`), control-plane assignment APIs | | Atomic leases/sessions | `control_plane_db.py` (`assign_and_lease`), `issue_lock_store.py`, `pr_work_lease.py` | | Capability / namespace | capability resolver, `namespace_workspace_binding.py`, `role_namespace_gate.py` | | Worktree binding | author/reviewer worktree modules, branches-only guards | | Issue/PR durable history | Gitea issues/PRs/comments/reviews/labels | | Workflow labels | `issue_workflow_labels.py`, #603 | | Canonical comments / CTH | `canonical_thread_handoff.py`, `canonical_state_comments.py`, `canonical_comment_validator.py` | | Thread-state ledger | `state_handoff_ledger.py`, `thread_state_ledger_validator.py` | | Final reports | `final_report_validator.py`, role final-report schemas | | Controller acceptance | `issue_acceptance_gate.py`, #500 | | Cleanup/reconcile | `merged_cleanup_reconcile.py`, reconciler workflows | ### Authority model (target) | Authority | Owns | |-----------|------| | **Gitea** | Durable issue/PR history, canonical handoffs/comments, reviews, labels, merge/close | | **Control-plane DB / allocator** | Atomic assignment, exclusive leases, session heartbeats, runnable queue coordination | | **Dependency graph (to add/extend)** | Structured edges, blocking/completion conditions, auto reevaluation | | **Canonical handoff store (Gitea + schema)** | Stage continuation payload for next worker | | **Capability/namespace gates** | Next-role eligibility and mutation authorization | | **Controller gate** | Terminal acceptance when required | Rule of thumb: **DB coordinates concurrency; Gitea records durable truth; handoff schema carries continuation; controller owns final acceptance; allocator delivers work without chat paste.** ### Where automatic continuation should occur 1. Stage completion tool path → validate + post canonical handoff + update assignment/dependency state. 2. Allocator startup path → retrieve assignment + latest handoff + live revalidation + lease bind. 3. Dependency completion event → reevaluate waiters → enqueue runnable roles. 4. Worker crash/lease expiry → sanctioned recovery → reassignment without duplicate ownership. 5. Defect discovery path → create/link issue → block dependent → keep unrelated runnable. ## Safety and architectural constraints * Fail closed on ambiguous ownership, stale head, or contradictory canonical state. * Do not bypass existing capability, role, lease, or controller gates. * Do not replace Gitea as durable history. * Do not auto-assign raw unclassified monitoring incidents. * Do not silently steal leases. * Do not treat chat-facing final reports as the system of record. * Model-agnostic: any LLM worker with correct profile/namespace can continue from Gitea + assignment only. ## Non-goals * Do not hard-code Issue #601 or PR #625 behavior as sole scope. * Do not require humans to paste reports between roles for normal flow. * Do not place project-specific acceptance criteria into generic workflow prompts. * Do not re-implement closed foundations (#494–#507, #500, #600, #601, #613) from scratch. * Do not solve unrelated namespace/worktree/runtime defects inside this umbrella unless required for orchestration correctness. * Do not dump full handoffs into normal user-facing responses. ## Acceptance criteria 1. Every non-terminal stage automatically stores a complete validated canonical handoff. 2. The next worker automatically retrieves the handoff. 3. No normal workflow transition requires the user to copy a prompt. 4. User-facing final responses are brief and do not duplicate the full handoff. 5. Multiple workers can process independent tasks concurrently. 6. The same exclusive task unit cannot have multiple active owners. 7. Assignments are role-, session-, namespace-, worktree-, and head-bound. 8. Dependencies are represented as durable structured state. 9. Blocked tasks are excluded from runnable assignment. 10. Unrelated runnable tasks continue while another task is blocked. 11. Dependency completion automatically reevaluates waiting tasks. 12. Resumed tasks revalidate live state before continuing. 13. Separate workflow defects are automatically linked as dependencies. 14. The workflow does not create duplicate defect work. 15. Changed PR heads invalidate stale review and merge eligibility. 16. A merged task remains non-terminal while required reconciliation remains. 17. Controller acceptance is enforced when required. 18. Terminal tasks produce no unnecessary next assignment. 19. Routine progress requires no user monitoring or redirection. 20. User intervention is requested only at the defined attention boundary. 21. Tests cover: * automatic author-to-reviewer handoff; * reviewer-to-author handoff; * reviewer-to-merger handoff; * merger-to-reconciler handoff; * reconciler-to-controller handoff; * controller-to-terminal completion; * two independent issues worked concurrently; * duplicate assignment rejection; * same PR head review collision; * changed-head invalidation; * dependency blocking; * unrelated task progress during a block; * automatic dependency resumption; * tooling-defect dependency; * stale lease recovery; * worker crash and reassignment; * brief user-facing response; * complete canonical backend handoff; * operation without external chat history. ## Implementation investigation notes * Prefer extending `allocate_next_work` + control-plane assignment to return handoff reference + machine continuation package. * Prefer extending final-report and comment validators to require handoff post + brief user-facing separation. * Prefer a structured dependency table/index (control-plane and/or durable Gitea-mirrored comments) rather than prose-only blockers. * #626 remains the focused handoff-schema/enforcement track; this umbrella owns end-to-end autonomy, concurrency, dependency orchestration, and user-attention policy. * Controller triage should establish implementation order across #626, #603, #605, #604, dependency graph, and allocator retrieval wiring.
jcwalker3 added the status:readyallocatorqueueworkflow-hardeningtype:feature labels 2026-07-10 11:57:35 -05:00
jcwalker3 commented 2026-07-10 11:58:01 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE:
needs-controller-triage

WHO_IS_NEXT:
controller

NEXT_ACTION:
Review scope, identify existing component issues, define architecture ownership, and establish implementation order

CONTINUATION:
Stored automatically in canonical workflow state for controller retrieval. Normal operation must not require the user to paste this prompt.

NEXT_PROMPT:

You are the CONTROLLER session for Scaled-Tech-Consulting/Gitea-Tools on remote prgs.

Retrieve live Issue #628 and this canonical state. Do not rely on chat history.

Task: needs-controller-triage for umbrella issue "Enforce autonomous canonical handoffs and dependency-aware concurrent task orchestration".

1. Verify identity/profile and resolve controller capabilities.
2. Confirm this is the integration umbrella; do not recreate #626 or closed #600/#601/#613.
3. Map architecture ownership: Gitea (durable handoffs/history), control-plane DB/allocator (assignment/leases), dependency graph (blocking/resume), controller (terminal acceptance).
4. Establish implementation order across #626 (handoff store/retrieve), allocator retrieval packaging, dependency graph, brief user-facing report separation, #603/#605/#604 as needed.
5. Post updated canonical issue state with next actor (likely author for first slice) or further controller decisions.
6. Do not implement code in controller session unless explicitly authorized for a narrow control-plane-only change.

Prohibited: human-required prompt paste as normal path; duplicate component issues; silent lease steal; bypassing gates.

WHAT_HAPPENED:
Created durable umbrella issue #628 for automatic handoff retrieval, dependency-aware scheduling, concurrent workers, exclusive leases, and minimal user-facing reports. Duplicate search found no exact owner; #626 owns handoff enforcement through controller closure as a component, not full autonomy/orchestration.

WHY:
The workflow must advance safely without requiring the user to transfer prompts or continuously direct each stage.

RELATED_ISSUES:

  • #626 self-propagating canonical handoffs / controller closure (primary handoff component)
  • #600 allocator (closed)
  • #601 leases (closed)
  • #613 control-plane DB (closed)
  • #603 lifecycle labels (open)
  • #605 queue dashboard (open)
  • #604 anti-stomp preflight (open)
  • #627 label-pagination defect (example tooling dependency from #601/#625 lifecycle)
  • #494 #495 #496 #500 #501 #505 #507 foundational handoff/controller schemas (closed)

RELATED_PRS:

  • #625 as one lifecycle evidence example
  • other PRs to be discovered during controller triage / implementation inventory

BLOCKERS:
none for intake; architectural implementation order requires controller triage before author claim

VALIDATION:
Duplicate search across open/closed issues completed; component scope comparison completed; architecture ownership table recorded in issue body; no implementation begun

LAST_UPDATED_BY:
jcwalker3 / prgs-author / author / 2026-07-10T issue-intake

## Canonical Issue State STATE: needs-controller-triage WHO_IS_NEXT: controller NEXT_ACTION: Review scope, identify existing component issues, define architecture ownership, and establish implementation order CONTINUATION: Stored automatically in canonical workflow state for controller retrieval. Normal operation must not require the user to paste this prompt. NEXT_PROMPT: ```text You are the CONTROLLER session for Scaled-Tech-Consulting/Gitea-Tools on remote prgs. Retrieve live Issue #628 and this canonical state. Do not rely on chat history. Task: needs-controller-triage for umbrella issue "Enforce autonomous canonical handoffs and dependency-aware concurrent task orchestration". 1. Verify identity/profile and resolve controller capabilities. 2. Confirm this is the integration umbrella; do not recreate #626 or closed #600/#601/#613. 3. Map architecture ownership: Gitea (durable handoffs/history), control-plane DB/allocator (assignment/leases), dependency graph (blocking/resume), controller (terminal acceptance). 4. Establish implementation order across #626 (handoff store/retrieve), allocator retrieval packaging, dependency graph, brief user-facing report separation, #603/#605/#604 as needed. 5. Post updated canonical issue state with next actor (likely author for first slice) or further controller decisions. 6. Do not implement code in controller session unless explicitly authorized for a narrow control-plane-only change. Prohibited: human-required prompt paste as normal path; duplicate component issues; silent lease steal; bypassing gates. ``` WHAT_HAPPENED: Created durable umbrella issue #628 for automatic handoff retrieval, dependency-aware scheduling, concurrent workers, exclusive leases, and minimal user-facing reports. Duplicate search found no exact owner; #626 owns handoff enforcement through controller closure as a component, not full autonomy/orchestration. WHY: The workflow must advance safely without requiring the user to transfer prompts or continuously direct each stage. RELATED_ISSUES: - #626 self-propagating canonical handoffs / controller closure (primary handoff component) - #600 allocator (closed) - #601 leases (closed) - #613 control-plane DB (closed) - #603 lifecycle labels (open) - #605 queue dashboard (open) - #604 anti-stomp preflight (open) - #627 label-pagination defect (example tooling dependency from #601/#625 lifecycle) - #494 #495 #496 #500 #501 #505 #507 foundational handoff/controller schemas (closed) RELATED_PRS: - #625 as one lifecycle evidence example - other PRs to be discovered during controller triage / implementation inventory BLOCKERS: none for intake; architectural implementation order requires controller triage before author claim VALIDATION: Duplicate search across open/closed issues completed; component scope comparison completed; architecture ownership table recorded in issue body; no implementation begun LAST_UPDATED_BY: jcwalker3 / prgs-author / author / 2026-07-10T issue-intake
jcwalker3 commented 2026-07-12 01:01:49 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE:
needs-controller-triage

WHO_IS_NEXT:
controller

NEXT_ACTION:
Continue implementation-order triage using soft-vs-hard dependency rules validated on issues 606 and 607; do not invent hard blocks from pairs-with prose.

NEXT_PROMPT:

Role: CONTROLLER
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools
Issue: 628

Continue controller triage for autonomous handoffs and dependency-aware orchestration.
Use the 606/607 validation already recorded on this issue:
- soft relatedness must not set dependency_unmet
- hard deps require status:blocked and/or body "blocked on #N"
- inventory limit truncation is a separate regression class
Do not implement application code in controller session unless authorized.

WHAT_HAPPENED:
Controller validated allocator selection of issue 607 while issue 606 remained open. Not a hard-dependency defect. Clarification posted on issue 607 (comment 10436). No status:blocked mutation. Dry-run allocate_next_work role=author limit=50 selected issue 607 (valid). Issues-only limit=100 selected issue 604 (older ready wins; inventory completeness note). Soft dogfood order 606 then 607 is advisory only.

WHY:
This umbrella owns durable dependency orchestration; prose pairs-with must not be over-inferred as a hard block. Hard deps need durable signals the allocator already understands until the structured dependency graph lands.

RELATED_PRS:
no open PR for this validation slice

BLOCKERS:
none

VALIDATION:

  • allocate_next_work apply=false role=author limit=50 selected issue 607 (valid eligibility)
  • allocate_next_work issues-only limit=100 selected issue 604
  • issues 606 and 607 both status:ready; clarification comment_id=10436 on issue 607
  • regression coverage: soft pairs-with; hard blocked-on marker; status:blocked; inventory limit completeness; parallel siblings

LAST_UPDATED_BY:
jcwalker3 / prgs-author / controller session / 2026-07-12

## Canonical Issue State STATE: needs-controller-triage WHO_IS_NEXT: controller NEXT_ACTION: Continue implementation-order triage using soft-vs-hard dependency rules validated on issues 606 and 607; do not invent hard blocks from pairs-with prose. NEXT_PROMPT: ```text Role: CONTROLLER Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools Issue: 628 Continue controller triage for autonomous handoffs and dependency-aware orchestration. Use the 606/607 validation already recorded on this issue: - soft relatedness must not set dependency_unmet - hard deps require status:blocked and/or body "blocked on #N" - inventory limit truncation is a separate regression class Do not implement application code in controller session unless authorized. ``` WHAT_HAPPENED: Controller validated allocator selection of issue 607 while issue 606 remained open. Not a hard-dependency defect. Clarification posted on issue 607 (comment 10436). No status:blocked mutation. Dry-run allocate_next_work role=author limit=50 selected issue 607 (valid). Issues-only limit=100 selected issue 604 (older ready wins; inventory completeness note). Soft dogfood order 606 then 607 is advisory only. WHY: This umbrella owns durable dependency orchestration; prose pairs-with must not be over-inferred as a hard block. Hard deps need durable signals the allocator already understands until the structured dependency graph lands. RELATED_PRS: no open PR for this validation slice BLOCKERS: none VALIDATION: - allocate_next_work apply=false role=author limit=50 selected issue 607 (valid eligibility) - allocate_next_work issues-only limit=100 selected issue 604 - issues 606 and 607 both status:ready; clarification comment_id=10436 on issue 607 - regression coverage: soft pairs-with; hard blocked-on marker; status:blocked; inventory limit completeness; parallel siblings LAST_UPDATED_BY: jcwalker3 / prgs-author / controller session / 2026-07-12
jcwalker3 commented 2026-07-12 01:02:13 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE:
ready-for-author

WHO_IS_NEXT:
author

NEXT_ACTION:
Author claims the allocator-selected next work item (issue 604) and implements only that scope; leave issues 606 and 607 unblocked and parallel-eligible.

NEXT_PROMPT:

Role: AUTHOR
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools

Invoke gitea-workflow skill first. Fail-closed: gitea_whoami, gitea_resolve_task_capability, runtime freshness vs prgs/master, branches/ worktree only.

Assigned work (controller allocator dry-run after 606/607 validation):
Issue 604 — Add anti-stomp preflight gate before every mutation tool

1. Re-verify live issue state and canonical comments for issue 604.
2. Acquire exclusive lease with gitea_lock_issue (do not self-select other exclusive work).
3. Implement only issue 604 acceptance criteria on a branches/ worktree from fresh master.
4. Open one PR; stop for reviewer. Do not review/merge own work.
5. Post canonical author handoff on the issue/PR.

Note: issues 606 and 607 remain parallel-eligible status:ready (607 not hard-blocked on 606). Do not implement them in this session unless the allocator assigns them.

WHAT_HAPPENED:
Controller finished 606/607 dependency validation. Durable clarification on issue 607 (comment 10436). Validation record on this issue (comment 10439). Post-correction allocator dry-run selected issue 604 as next valid author work.

WHY:
607 selection while 606 open is valid soft-relatedness; hard block was not warranted. Global author queue then returns oldest equal-priority ready issue (604) when inventory limit is adequate.

RELATED_PRS:
no open PR for this handoff

BLOCKERS:
none

VALIDATION:

  • whoami jcwalker3 prgs-author; HEAD matches prgs/master 22698c1
  • allocate_next_work apply=false role=author include_issues=true include_prs=false limit=100 -> selected issue 604 priority 20 candidate_count 56
  • issue 607 remains status:ready (not status:blocked)
  • no apply=true lease created in controller session

LAST_UPDATED_BY:
jcwalker3 / prgs-author / controller session / 2026-07-12

## Canonical Issue State STATE: ready-for-author WHO_IS_NEXT: author NEXT_ACTION: Author claims the allocator-selected next work item (issue 604) and implements only that scope; leave issues 606 and 607 unblocked and parallel-eligible. NEXT_PROMPT: ```text Role: AUTHOR Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools Invoke gitea-workflow skill first. Fail-closed: gitea_whoami, gitea_resolve_task_capability, runtime freshness vs prgs/master, branches/ worktree only. Assigned work (controller allocator dry-run after 606/607 validation): Issue 604 — Add anti-stomp preflight gate before every mutation tool 1. Re-verify live issue state and canonical comments for issue 604. 2. Acquire exclusive lease with gitea_lock_issue (do not self-select other exclusive work). 3. Implement only issue 604 acceptance criteria on a branches/ worktree from fresh master. 4. Open one PR; stop for reviewer. Do not review/merge own work. 5. Post canonical author handoff on the issue/PR. Note: issues 606 and 607 remain parallel-eligible status:ready (607 not hard-blocked on 606). Do not implement them in this session unless the allocator assigns them. ``` WHAT_HAPPENED: Controller finished 606/607 dependency validation. Durable clarification on issue 607 (comment 10436). Validation record on this issue (comment 10439). Post-correction allocator dry-run selected issue 604 as next valid author work. WHY: 607 selection while 606 open is valid soft-relatedness; hard block was not warranted. Global author queue then returns oldest equal-priority ready issue (604) when inventory limit is adequate. RELATED_PRS: no open PR for this handoff BLOCKERS: none VALIDATION: - whoami jcwalker3 prgs-author; HEAD matches prgs/master 22698c1 - allocate_next_work apply=false role=author include_issues=true include_prs=false limit=100 -> selected issue 604 priority 20 candidate_count 56 - issue 607 remains status:ready (not status:blocked) - no apply=true lease created in controller session LAST_UPDATED_BY: jcwalker3 / prgs-author / controller session / 2026-07-12
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 queue status:ready type:feature workflow-hardening
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#628