MCP Control Plane: charter-compliant autonomous task selection (umbrella) #989

New Issue

2026-07-31T10:14:52-05:00

jcwalker3 commented

2026-07-31 10:14:52 -05:00

Problem

The approved charter requires every worker to follow inspect -> choose -> derive role -> validate -> claim -> work -> release -> reassess. A worker begins uncommitted, inspects authoritative Gitea state, compares candidates, chooses independently, derives a temporary role from that choice, asks the MCP to validate, claims, completes one bounded cycle, releases, and reassesses.

The implemented system runs a different order: a worker starts inside a role-bound namespace and obtains its task from a controller-owned allocator. Task selection, role derivation, and claim authority therefore sit in the wrong components.

This umbrella coordinates the architecture and sequencing that corrects it. It is not a rewrite of the safety substrate.

Charter connection

Supports all twelve fundamental-workflow steps and governs remediation needed to operationalize non-negotiable principles 1 through 14. Directly governed by:

Fundamental workflow, Bounded work cycle, Contention is normal
Responsibilities — "The MCP may reject an unsafe or stale choice. It must not decide which task the LLM wants or permanently assign the LLM a role," plus the guardrail that a pattern of rejections which routes workers toward particular tasks means the MCP has become a dispatcher and the design has been violated
Roles — "An LLM never begins a cycle already holding one of these roles"
Identity and independence; Approval, parity, and remediation
Project state model requirements; Escalation
What this project is not — no dispatcher, no allocator authoritative over the LLM's decision
Definition of success — initial target of 10 consecutive autonomous issue-to-merge cycles

Verified current gap

Verified against live state at master 0ba19c8436d292c813ff04d34cdf82cf23a0adc0:

Role-bound worker entry. Every namespace binds a fixed role profile at session start; identity surfaces report a role kind before any task is chosen. There is no neutral entry.

Allocator-selected work under #600. The allocator's contract instructs workers not to self-select and to call it instead; with apply enabled it atomically assigns and leases. Closed issue #600 states "LLMs should not manually choose a PR/issue when using the standard workflow" and "The allocator must reserve the selected item atomically before returning it."

Role-oriented recommendations under #605. The only unified queue surface emits a primary next-safe-action and per-role next targets. Closed issue #605 requires "exact prompts for next safe author/reviewer/merger/controller action" and records that "assignment still goes through the allocator (#600)."

Database-authoritative claims. Workflow leases report authoritative_source: control_plane_db, file_lock_only: false, comment_lease_only: false. Active ownership is not machine-discoverable in Gitea.

Incomplete neutral project-state inspection. The neutral list operations express none of priority, urgency, impact, claims, or dependencies. The issue listing exposes no pagination inputs and no completeness metadata and truncates silently — a request limited to 50 returned exactly 50 with no signal. The only surface asserting inventory completeness is the non-neutral dashboard.

Missing authoritative state. The repository label catalog contains no representation for priority, urgency, project impact, or blocked-pending-clarification. Dependencies exist durably but in the control plane, not Gitea. Active claims are exposed only in aggregate.

Missing sanctioned relationship-write operations. No native operation creates a Gitea parent/child or hard-dependency relationship. The dependency-edge listing is read-only and its contract states edges are recorded by the allocator — so the only mechanism that currently produces dependency edges is the component this program removes from normal operation.

Unsafe conflation of commenting with title/body editing. Capability resolution maps the issue-edit task to the issue-comment permission, and no distinct issue-edit permission exists in any profile. Comment authority is being accepted as proof of authority to rewrite an issue's title and body.

Safety-infrastructure status

Substantial reusable safety infrastructure exists, but individual guarantees must be verified and may remain pending, incomplete, or defective.

No child may assume a guarantee holds because a related issue or tool exists.

Verified reusable mechanisms — observed live during this program: authenticated identity and identity match; repository and session binding; the master-parity mutation gate with enforcement flag; runtime provenance; capability resolution and per-profile allow and forbid sets; caller-addressable lock and lease acquisition writing durable control-plane rows; author-versus-approver eligibility refusal; typed fail-closed refusals reporting no mutation performed.

Claimed but unverified: exact-head approval enforcement and approval invalidation after new commits — specified in #916, which is open with no labels, no comments, and no linked pull request; no enforcement path was inspected. Handoff durability. Reconciliation completeness.

Open remediation: #793 read-side generation unchecked in mutation verification; #792 terminal retirement unimplemented; #952 inspector, dashboard, resolver, and executor disagree on one lease state; #890 seven ownership stores disagree; #891 four-step finalization not transactional, requiring #816; #889 capability-call adjacency; #895 failure reporting lost after a hard stop; #873 author workflow loading.

New requirements introduced by this program: Gitea-authoritative active-claim record and reconciliation; field authorities for priority, dependencies, urgency, impact, readiness, clarification state, and claims; the blocked-pending-clarification marker; sanctioned structured relationship operations; a distinct issue-edit permission; neutral worker entry and task-scoped capability lifecycle; unified neutral inventory; unified validate-and-claim; the thin worker surface; allocator-first and role-first removal.

Scope

Establish the target architecture and the authority boundaries between the LLM, Gitea, the Gitea MCP, and the Control Plane. Define the remediation sequence and the integration gates. Link the bounded implementation issues. Prevent any child from independently reintroducing allocator-first or role-first behaviour. Track completion of the program.

Authority boundaries, binding on every child:

Component	Owns	Must never
LLM	Understanding the project, comparing candidates, choosing the task	Depend on session memory or prompts as coordination state
Gitea	Authoritative issues, PRs, priorities, dependencies, decisions, active claims, history	Be bypassed as the durable record of active ownership
Gitea MCP	Exposing live facts; sanctioned operations; validating or rejecting a caller's choice	Allocate, recommend, rank through hidden policy, substitute, or steer
Control plane	Atomic enforcement, caching, indexing, fencing; short-lived reservation during publication	Be the sole durable authority for a claim
Locks and leases	Preventing conflicting exclusive work after a choice	Become the record of what work exists
Human maintainer	Setting priorities, approving charter changes, resolving escalations	—

Integration gates. Children 1 through 5 must all integrate before certification under #963.

G1 — Child 1: every candidate fact has a named durable Gitea authority or an explicit typed state gap; Gitea holds the authoritative active claim; the clarification marker exists; structured relationship operations exist; a distinct issue-edit permission exists.
G2 — Child 2: one unified neutral inventory, provably complete, emitting no ranking, selection, or recommendation.
G3 — Child 3: an uncommitted worker enters neutrally, selects a task, receives task-scoped capability only after authoritative claim publication, and claims atomically.
G4 — Child 4: a worker completes a bounded cycle, releases, returns to neutral, and reassesses without calling the allocator.
G5 — Child 5: no normal path requires allocator selection or a pre-bound role.
G6 — #963, once revisable, certifies concurrency and the 10-cycle target.

Non-goals

Implementation. No implementation PR may close this umbrella.
Rewriting or removing the safety substrate.
Reducing tool count as an objective; tool count is not a success metric.
Removing low-level tools needed for composition, diagnostics, administration, recovery, or reconciliation.
Re-deciding whether autonomous task selection is permitted — the approved charter settles it.

Functional requirements

The program is complete when a general worker executes the charter order end to end using only sanctioned native operations, and the MCP validates without allocating.

Anti-regression rule. No child may introduce, restore, or preserve: MCP-side ranking or recommendation on a normal worker path; a role or task-scoped capability bound before task selection; an active claim whose sole durable authority is the control-plane database; a rejection payload naming a substitute task; automatic retry of a failed claim; or a rollback path restoring allocator assignment.

Safety and authority boundaries

Preserve existing guarantees as classified above, verifying rather than assuming. Defective implementations may be corrected where a verified defect requires it.

Acceptance criteria

All five bounded children exist, reference this umbrella, are independently governable, and state their sequencing dependencies explicitly.
Gates G1 through G5 are each demonstrated by the owning child's own acceptance criteria.
A general worker completes a full charter cycle without calling the allocator.
Rejection and eligibility rules exist as durable reviewable Gitea artifacts and are audited for routing patterns.
No merged child behaviour violates the anti-regression rule.
Every guarantee a child relies on is reclassified from claimed to verified with evidence, or that child records the dependency as pending.
Structured relationships replace the bootstrap body references recorded during creation.
No product feature is claimed complete on this issue alone.

Required tests and validation

Linkage integrity across children. An anti-regression contract test asserting no normal worker path requires the allocator and no normal path emits a recommended task. Per-gate evidence recorded in Gitea.

Dependencies

Until Child 1 delivers sanctioned structured relationship operations, the references below are informative bootstrap evidence only. They must not be treated as machine-enforced hard dependencies. Child 1 must backfill the appropriate structured relationships.

Children 1 through 5. Consumed, not restated: #889, #890, #891, #895, #873, #952, #792, #793, #816. Referenced: #916, #963, #964, #987. Behaviour superseded by Child 5: #600, #605.

Deferred certification revision — #963. The approved expansion of #963 remains pending and was deliberately not applied. Capability resolution currently routes issue editing through the issue-comment permission, and no distinct issue-edit permission exists, so title and body edit authority is not safely established. #963 may be revised only after Child 1 delivers the distinct edit permission and the author profile is intentionally granted it. When revised, #963 must preserve its existing five-client canary and negative-suite requirements and must add one-worker, two-worker, four-worker, and 10-consecutive-cycle charter certification requirements.

#916. Exact-head enforcement remains pending or Unverified unless later authoritative evidence proves delivery. #916 is untouched and remains so until Child 1 establishes the sanctioned blocked-pending-clarification marker and policy.

Compatibility and rollout

Children 1 through 3 are additive. Compatibility is proven by schema-compatibility and semantic contract tests under deterministic fixtures with nondeterministic values normalized — never by literal byte comparison of live responses, which legitimately carry changing project state. Intentional breaking changes require explicit versioning and a documented migration.

Allocator behaviour with apply enabled assigns and leases work and is therefore authoritative allocation, not advisory. Only a read-only, non-assigning invocation may be retained, and only outside the normal worker path.

Rollback behavior

Disabling the new workflow stops autonomous cycles safely: admit no new claims; allow an in-flight cycle to finish only while every identity, capability, parity, ownership, and lease gate remains valid; otherwise fail closed, record a durable handoff, release safely, and halt. Rollback must never restore allocator-selected assignment, allocator-created claims, permanent roles, or role-first task discovery.

Documentation requirements

One architecture document covering the authority table, the charter order, the integration gates, and the safety-classification table above.

Completion evidence

Child issue numbers, per-gate evidence, merge commits, the anti-regression test result, the reclassification of each relied-upon guarantee, the structured-relationship backfill, and the #963 certification result — all recorded on this issue.

Reusable existing issues, PRs, and primitives

#889, #890, #891, #895, #873, #952, #792, #793, #816, #916, #963, #964, #987. Live primitives: issue locking; reviewer and merger lease acquisition and adoption; task capability resolution; PR eligibility checking; master-parity assessment; dependency-edge listing; workflow-lease listing; PR review-feedback reading.

Fundamental-workflow stage supported

All stages — inspect -> choose -> derive role -> validate -> claim -> work -> release -> reassess. This issue owns architecture and sequencing only.

Implementation authorization

This umbrella coordinates architecture and sequencing and does not authorize implementation. Per AGENTS.md, work begins only under a bounded child issue, and every implementation PR must reference that child.

Bootstrap note

Child issues created during bootstrap reference this umbrella by issue number in their bodies. Those references are informative bootstrap evidence only. No native structured parent/child or dependency relationship was established, because no sanctioned relationship-write operation exists. Child 1 delivers those operations and backfills the relationships.

## Problem The approved charter requires every worker to follow inspect -> choose -> derive role -> validate -> claim -> work -> release -> reassess. A worker begins uncommitted, inspects authoritative Gitea state, compares candidates, chooses independently, derives a temporary role from that choice, asks the MCP to validate, claims, completes one bounded cycle, releases, and reassesses. The implemented system runs a different order: a worker starts inside a role-bound namespace and obtains its task from a controller-owned allocator. Task selection, role derivation, and claim authority therefore sit in the wrong components. This umbrella coordinates the architecture and sequencing that corrects it. It is not a rewrite of the safety substrate. ## Charter connection Supports all twelve fundamental-workflow steps and governs remediation needed to operationalize non-negotiable principles 1 through 14. Directly governed by: - Fundamental workflow, Bounded work cycle, Contention is normal - Responsibilities — "The MCP may reject an unsafe or stale choice. It must not decide which task the LLM wants or permanently assign the LLM a role," plus the guardrail that a pattern of rejections which routes workers toward particular tasks means the MCP has become a dispatcher and the design has been violated - Roles — "An LLM never begins a cycle already holding one of these roles" - Identity and independence; Approval, parity, and remediation - Project state model requirements; Escalation - What this project is not — no dispatcher, no allocator authoritative over the LLM's decision - Definition of success — initial target of 10 consecutive autonomous issue-to-merge cycles ## Verified current gap Verified against live state at master `0ba19c8436d292c813ff04d34cdf82cf23a0adc0`: **Role-bound worker entry.** Every namespace binds a fixed role profile at session start; identity surfaces report a role kind before any task is chosen. There is no neutral entry. **Allocator-selected work under #600.** The allocator's contract instructs workers not to self-select and to call it instead; with apply enabled it atomically assigns and leases. Closed issue #600 states "LLMs should not manually choose a PR/issue when using the standard workflow" and "The allocator must reserve the selected item atomically before returning it." **Role-oriented recommendations under #605.** The only unified queue surface emits a primary next-safe-action and per-role next targets. Closed issue #605 requires "exact prompts for next safe author/reviewer/merger/controller action" and records that "assignment still goes through the allocator (#600)." **Database-authoritative claims.** Workflow leases report `authoritative_source: control_plane_db`, `file_lock_only: false`, `comment_lease_only: false`. Active ownership is not machine-discoverable in Gitea. **Incomplete neutral project-state inspection.** The neutral list operations express none of priority, urgency, impact, claims, or dependencies. The issue listing exposes no pagination inputs and no completeness metadata and truncates silently — a request limited to 50 returned exactly 50 with no signal. The only surface asserting inventory completeness is the non-neutral dashboard. **Missing authoritative state.** The repository label catalog contains no representation for priority, urgency, project impact, or blocked-pending-clarification. Dependencies exist durably but in the control plane, not Gitea. Active claims are exposed only in aggregate. **Missing sanctioned relationship-write operations.** No native operation creates a Gitea parent/child or hard-dependency relationship. The dependency-edge listing is read-only and its contract states edges are recorded by the allocator — so the only mechanism that currently produces dependency edges is the component this program removes from normal operation. **Unsafe conflation of commenting with title/body editing.** Capability resolution maps the issue-edit task to the issue-comment permission, and no distinct issue-edit permission exists in any profile. Comment authority is being accepted as proof of authority to rewrite an issue's title and body. ## Safety-infrastructure status Substantial reusable safety infrastructure exists, but individual guarantees must be verified and may remain pending, incomplete, or defective. No child may assume a guarantee holds because a related issue or tool exists. **Verified reusable mechanisms** — observed live during this program: authenticated identity and identity match; repository and session binding; the master-parity mutation gate with enforcement flag; runtime provenance; capability resolution and per-profile allow and forbid sets; caller-addressable lock and lease acquisition writing durable control-plane rows; author-versus-approver eligibility refusal; typed fail-closed refusals reporting no mutation performed. **Claimed but unverified:** exact-head approval enforcement and approval invalidation after new commits — specified in #916, which is open with no labels, no comments, and no linked pull request; no enforcement path was inspected. Handoff durability. Reconciliation completeness. **Open remediation:** #793 read-side generation unchecked in mutation verification; #792 terminal retirement unimplemented; #952 inspector, dashboard, resolver, and executor disagree on one lease state; #890 seven ownership stores disagree; #891 four-step finalization not transactional, requiring #816; #889 capability-call adjacency; #895 failure reporting lost after a hard stop; #873 author workflow loading. **New requirements introduced by this program:** Gitea-authoritative active-claim record and reconciliation; field authorities for priority, dependencies, urgency, impact, readiness, clarification state, and claims; the blocked-pending-clarification marker; sanctioned structured relationship operations; a distinct issue-edit permission; neutral worker entry and task-scoped capability lifecycle; unified neutral inventory; unified validate-and-claim; the thin worker surface; allocator-first and role-first removal. ## Scope Establish the target architecture and the authority boundaries between the LLM, Gitea, the Gitea MCP, and the Control Plane. Define the remediation sequence and the integration gates. Link the bounded implementation issues. Prevent any child from independently reintroducing allocator-first or role-first behaviour. Track completion of the program. **Authority boundaries, binding on every child:** | Component | Owns | Must never | | --- | --- | --- | | LLM | Understanding the project, comparing candidates, choosing the task | Depend on session memory or prompts as coordination state | | Gitea | Authoritative issues, PRs, priorities, dependencies, decisions, active claims, history | Be bypassed as the durable record of active ownership | | Gitea MCP | Exposing live facts; sanctioned operations; validating or rejecting a caller's choice | Allocate, recommend, rank through hidden policy, substitute, or steer | | Control plane | Atomic enforcement, caching, indexing, fencing; short-lived reservation during publication | Be the sole durable authority for a claim | | Locks and leases | Preventing conflicting exclusive work after a choice | Become the record of what work exists | | Human maintainer | Setting priorities, approving charter changes, resolving escalations | — | **Integration gates.** Children 1 through 5 must all integrate before certification under #963. - **G1 — Child 1:** every candidate fact has a named durable Gitea authority or an explicit typed state gap; Gitea holds the authoritative active claim; the clarification marker exists; structured relationship operations exist; a distinct issue-edit permission exists. - **G2 — Child 2:** one unified neutral inventory, provably complete, emitting no ranking, selection, or recommendation. - **G3 — Child 3:** an uncommitted worker enters neutrally, selects a task, receives task-scoped capability only after authoritative claim publication, and claims atomically. - **G4 — Child 4:** a worker completes a bounded cycle, releases, returns to neutral, and reassesses without calling the allocator. - **G5 — Child 5:** no normal path requires allocator selection or a pre-bound role. - **G6 — #963,** once revisable, certifies concurrency and the 10-cycle target. ## Non-goals - Implementation. No implementation PR may close this umbrella. - Rewriting or removing the safety substrate. - Reducing tool count as an objective; tool count is not a success metric. - Removing low-level tools needed for composition, diagnostics, administration, recovery, or reconciliation. - Re-deciding whether autonomous task selection is permitted — the approved charter settles it. ## Functional requirements The program is complete when a general worker executes the charter order end to end using only sanctioned native operations, and the MCP validates without allocating. **Anti-regression rule.** No child may introduce, restore, or preserve: MCP-side ranking or recommendation on a normal worker path; a role or task-scoped capability bound before task selection; an active claim whose sole durable authority is the control-plane database; a rejection payload naming a substitute task; automatic retry of a failed claim; or a rollback path restoring allocator assignment. ## Safety and authority boundaries Preserve existing guarantees as classified above, verifying rather than assuming. Defective implementations may be corrected where a verified defect requires it. ## Acceptance criteria - All five bounded children exist, reference this umbrella, are independently governable, and state their sequencing dependencies explicitly. - Gates G1 through G5 are each demonstrated by the owning child's own acceptance criteria. - A general worker completes a full charter cycle without calling the allocator. - Rejection and eligibility rules exist as durable reviewable Gitea artifacts and are audited for routing patterns. - No merged child behaviour violates the anti-regression rule. - Every guarantee a child relies on is reclassified from claimed to verified with evidence, or that child records the dependency as pending. - Structured relationships replace the bootstrap body references recorded during creation. - No product feature is claimed complete on this issue alone. ## Required tests and validation Linkage integrity across children. An anti-regression contract test asserting no normal worker path requires the allocator and no normal path emits a recommended task. Per-gate evidence recorded in Gitea. ## Dependencies Until Child 1 delivers sanctioned structured relationship operations, the references below are informative bootstrap evidence only. They must not be treated as machine-enforced hard dependencies. Child 1 must backfill the appropriate structured relationships. Children 1 through 5. Consumed, not restated: #889, #890, #891, #895, #873, #952, #792, #793, #816. Referenced: #916, #963, #964, #987. Behaviour superseded by Child 5: #600, #605. **Deferred certification revision — #963.** The approved expansion of #963 remains pending and was deliberately not applied. Capability resolution currently routes issue editing through the issue-comment permission, and no distinct issue-edit permission exists, so title and body edit authority is not safely established. #963 may be revised only after Child 1 delivers the distinct edit permission and the author profile is intentionally granted it. When revised, #963 must preserve its existing five-client canary and negative-suite requirements and must add one-worker, two-worker, four-worker, and 10-consecutive-cycle charter certification requirements. **#916.** Exact-head enforcement remains pending or Unverified unless later authoritative evidence proves delivery. #916 is untouched and remains so until Child 1 establishes the sanctioned blocked-pending-clarification marker and policy. ## Compatibility and rollout Children 1 through 3 are additive. Compatibility is proven by schema-compatibility and semantic contract tests under deterministic fixtures with nondeterministic values normalized — never by literal byte comparison of live responses, which legitimately carry changing project state. Intentional breaking changes require explicit versioning and a documented migration. Allocator behaviour with apply enabled assigns and leases work and is therefore authoritative allocation, not advisory. Only a read-only, non-assigning invocation may be retained, and only outside the normal worker path. ## Rollback behavior Disabling the new workflow stops autonomous cycles safely: admit no new claims; allow an in-flight cycle to finish only while every identity, capability, parity, ownership, and lease gate remains valid; otherwise fail closed, record a durable handoff, release safely, and halt. Rollback must never restore allocator-selected assignment, allocator-created claims, permanent roles, or role-first task discovery. ## Documentation requirements One architecture document covering the authority table, the charter order, the integration gates, and the safety-classification table above. ## Completion evidence Child issue numbers, per-gate evidence, merge commits, the anti-regression test result, the reclassification of each relied-upon guarantee, the structured-relationship backfill, and the #963 certification result — all recorded on this issue. ## Reusable existing issues, PRs, and primitives #889, #890, #891, #895, #873, #952, #792, #793, #816, #916, #963, #964, #987. Live primitives: issue locking; reviewer and merger lease acquisition and adoption; task capability resolution; PR eligibility checking; master-parity assessment; dependency-edge listing; workflow-lease listing; PR review-feedback reading. ## Fundamental-workflow stage supported All stages — inspect -> choose -> derive role -> validate -> claim -> work -> release -> reassess. This issue owns architecture and sequencing only. ## Implementation authorization This umbrella coordinates architecture and sequencing and does not authorize implementation. Per AGENTS.md, work begins only under a bounded child issue, and every implementation PR must reference that child. ## Bootstrap note Child issues created during bootstrap reference this umbrella by issue number in their bodies. Those references are informative bootstrap evidence only. No native structured parent/child or dependency relationship was established, because no sanctioned relationship-write operation exists. Child 1 delivers those operations and backfills the relationships.

jcwalker3 referenced this issue

2026-07-31 10:16:24 -05:00

Authoritative Gitea candidate-state schema, claims, and relationships #990

jcwalker3 referenced this issue

2026-07-31 10:17:15 -05:00

Neutral unified project-state inspection #991

jcwalker3 referenced this issue

2026-07-31 10:18:17 -05:00

Neutral worker activation, caller-selected validation, and atomic claim #992

jcwalker3 referenced this issue

2026-07-31 10:19:14 -05:00

Thin task-oriented completion, release, and reassessment workflow #993