Remove allocator-first and role-first normal operation #994

New Issue

2026-07-31T10:20:10-05:00

jcwalker3 commented

2026-07-31 10:20:10 -05:00

Parent umbrella: issue #989. Informative bootstrap evidence only, not a machine-enforced dependency; Child 1 delivers structured relationships and backfills this.

Problem

Normal operation still begins with a bound role and an allocator-selected task. The preceding children build the compliant path; this issue removes the non-compliant one.

Charter connection

What this project is not forbids permanently launching an LLM as only one role, turning the MCP into a dispatcher including de facto dispatch through rejection policy, making a queue allocator authoritative over the LLM's decision, and choosing a role first then searching for fitting work. Roles states a worker never begins a cycle already holding a role. The Responsibilities guardrail requires rejection rules to be durable, reviewable Gitea artifacts so routing patterns can be audited.

Verified current gap

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 codifies both. The unified queue surface emits a primary next-safe-action and per-role next targets; closed issue #605 requires per-role next-action prompts and records that assignment goes through #600. The pre-task router classifies a task against the already-active profile. The readiness filter keyed on the ready status label makes label-less open issues unselectable — a routing pattern requiring audit.

Scope

Remove role-first startup guidance from normal autonomous operation. Remove allocator-selected work from the normal worker path. Classify apply-enabled allocation as authoritative allocation. Permit retained allocator components only when read-only, non-assigning, and outside normal worker operation. Ensure no normal path emits a recommended task or per-role next target. Make rejection and eligibility rules durable and reviewable in Gitea. Audit whether ready-status filtering creates de facto steering. Contain and sunset legacy role-scoped compatibility paths. Correct charter-conflicting workflow and dashboard guidance where authorized.

Non-goals

Deleting the allocator or the dashboard. Removing diagnostic, recovery, administrative, or reconciliation tooling. Editing, reopening, or closing #600 or #605 — they are closed historical records, superseded in behaviour, not retracted. Weakening any safety guarantee.

Functional requirements

Apply-enabled allocation is authoritative allocation, not advisory, because it assigns and leases. It may not be relabelled advisory while retaining that behaviour.
Only a read-only, non-assigning invocation — writing no assignment and no lease — may be retained, and only outside the normal worker path.
Legacy role-scoped compatibility is explicitly temporary, carries a stated sunset condition, is instrumented so residual dependence is visible, and must not become normal worker behaviour.
Dashboard changes are permitted only to remove charter-conflicting guidance.
Rejection and eligibility rules become durable reviewable Gitea artifacts, with a routing-pattern audit beginning with the ready-status filter.

Safety and authority boundaries

Preserve identity, capability, parity, provenance, ownership, lock, lease, independent-review, approval, handoff, fail-closed, and reconciliation behaviour as classified in the umbrella — verifying rather than assuming. Defective implementations may be corrected where a verified defect requires it.

Acceptance criteria

No normal worker path requires the allocator; a general worker completes a full cycle without calling it.
No normal worker path requires a role bound before task selection.
Apply-enabled allocation is documented and surfaced as authoritative allocation; no surface describes it as advisory.
Any retained allocator invocation on a compatibility path is read-only and non-assigning and is excluded from the normal worker path.
Legacy role-scoped compatibility is time-bounded, instrumented, and documented as temporary.
Charter-conflicting guidance is removed from the canonical workflow guide, the control-plane guide, the pre-task router's framing, and the dashboard's role prompts.
Rejection and eligibility rules exist as durable reviewable Gitea artifacts.
A routing-pattern audit reports whether eligibility filtering steers workers, covering the ready-status filter's effect on label-less open issues.
Rollback stops autonomous operation safely and cannot restore any prohibited behaviour — asserted by test.
Preserved safety behaviour remains, demonstrated by contract tests under deterministic fixtures.

Required tests and validation

A full cycle with the allocator unavailable. An assertion that no normal path emits a recommended task or per-role next target. An assertion that a compatibility allocator invocation writes no assignment and no lease. The rollback path asserted to halt rather than fall back. The routing-pattern audit. Contract tests for the retained diagnostic and recovery surfaces.

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.

Child 4 — the compliant path must exist before the non-compliant one is removed. References #600 and #605.

Compatibility and rollout

The only guidance-breaking step in the program. Legacy scheduled or role-scoped integrations may use an explicitly temporary compatibility path with a stated sunset, but that path is excluded from normal autonomous worker operation and cannot select, assign, or lease work for the worker. No path may require a general worker to accept an allocator-selected task during migration. Intentional breaking changes are versioned with documented migration.

Rollback behavior

Rollback stops autonomous operation 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. "It is the previous behaviour" is not an exemption; the approved charter controls the roadmap regardless of what shipped earlier.

Documentation requirements

Updated canonical workflow guide and control-plane guide. The published rejection-rule artifact. The compatibility boundary and sunset plan. A rollback procedure stating explicitly that allocator authority is never a rollback target.

Completion evidence

The allocator-free cycle recording, the routing-pattern audit result, and the rollback test result.

Reusable existing issues, PRs, and primitives

#600 and #605 — referenced, superseded in behaviour, not retracted. The existing allocator dry-run path as the basis for a read-only compatibility invocation.

Fundamental-workflow stage supported

inspect -> choose entry conditions — charter steps 1 and 5, plus What this project is not and the Responsibilities dispatcher guardrail.

Parent umbrella: issue #989. Informative bootstrap evidence only, not a machine-enforced dependency; Child 1 delivers structured relationships and backfills this. ## Problem Normal operation still begins with a bound role and an allocator-selected task. The preceding children build the compliant path; this issue removes the non-compliant one. ## Charter connection What this project is not forbids permanently launching an LLM as only one role, turning the MCP into a dispatcher including de facto dispatch through rejection policy, making a queue allocator authoritative over the LLM's decision, and choosing a role first then searching for fitting work. Roles states a worker never begins a cycle already holding a role. The Responsibilities guardrail requires rejection rules to be durable, reviewable Gitea artifacts so routing patterns can be audited. ## Verified current gap 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 codifies both. The unified queue surface emits a primary next-safe-action and per-role next targets; closed issue #605 requires per-role next-action prompts and records that assignment goes through #600. The pre-task router classifies a task against the already-active profile. The readiness filter keyed on the ready status label makes label-less open issues unselectable — a routing pattern requiring audit. ## Scope Remove role-first startup guidance from normal autonomous operation. Remove allocator-selected work from the normal worker path. Classify apply-enabled allocation as authoritative allocation. Permit retained allocator components only when read-only, non-assigning, and outside normal worker operation. Ensure no normal path emits a recommended task or per-role next target. Make rejection and eligibility rules durable and reviewable in Gitea. Audit whether ready-status filtering creates de facto steering. Contain and sunset legacy role-scoped compatibility paths. Correct charter-conflicting workflow and dashboard guidance where authorized. ## Non-goals Deleting the allocator or the dashboard. Removing diagnostic, recovery, administrative, or reconciliation tooling. Editing, reopening, or closing #600 or #605 — they are closed historical records, superseded in behaviour, not retracted. Weakening any safety guarantee. ## Functional requirements - Apply-enabled allocation is authoritative allocation, not advisory, because it assigns and leases. It may not be relabelled advisory while retaining that behaviour. - Only a read-only, non-assigning invocation — writing no assignment and no lease — may be retained, and only outside the normal worker path. - Legacy role-scoped compatibility is explicitly temporary, carries a stated sunset condition, is instrumented so residual dependence is visible, and must not become normal worker behaviour. - Dashboard changes are permitted only to remove charter-conflicting guidance. - Rejection and eligibility rules become durable reviewable Gitea artifacts, with a routing-pattern audit beginning with the ready-status filter. ## Safety and authority boundaries Preserve identity, capability, parity, provenance, ownership, lock, lease, independent-review, approval, handoff, fail-closed, and reconciliation behaviour as classified in the umbrella — verifying rather than assuming. Defective implementations may be corrected where a verified defect requires it. ## Acceptance criteria - No normal worker path requires the allocator; a general worker completes a full cycle without calling it. - No normal worker path requires a role bound before task selection. - Apply-enabled allocation is documented and surfaced as authoritative allocation; no surface describes it as advisory. - Any retained allocator invocation on a compatibility path is read-only and non-assigning and is excluded from the normal worker path. - Legacy role-scoped compatibility is time-bounded, instrumented, and documented as temporary. - Charter-conflicting guidance is removed from the canonical workflow guide, the control-plane guide, the pre-task router's framing, and the dashboard's role prompts. - Rejection and eligibility rules exist as durable reviewable Gitea artifacts. - A routing-pattern audit reports whether eligibility filtering steers workers, covering the ready-status filter's effect on label-less open issues. - Rollback stops autonomous operation safely and cannot restore any prohibited behaviour — asserted by test. - Preserved safety behaviour remains, demonstrated by contract tests under deterministic fixtures. ## Required tests and validation A full cycle with the allocator unavailable. An assertion that no normal path emits a recommended task or per-role next target. An assertion that a compatibility allocator invocation writes no assignment and no lease. The rollback path asserted to halt rather than fall back. The routing-pattern audit. Contract tests for the retained diagnostic and recovery surfaces. ## 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. Child 4 — the compliant path must exist before the non-compliant one is removed. References #600 and #605. ## Compatibility and rollout The only guidance-breaking step in the program. Legacy scheduled or role-scoped integrations may use an explicitly temporary compatibility path with a stated sunset, but that path is excluded from normal autonomous worker operation and cannot select, assign, or lease work for the worker. No path may require a general worker to accept an allocator-selected task during migration. Intentional breaking changes are versioned with documented migration. ## Rollback behavior Rollback stops autonomous operation 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. "It is the previous behaviour" is not an exemption; the approved charter controls the roadmap regardless of what shipped earlier. ## Documentation requirements Updated canonical workflow guide and control-plane guide. The published rejection-rule artifact. The compatibility boundary and sunset plan. A rollback procedure stating explicitly that allocator authority is never a rollback target. ## Completion evidence The allocator-free cycle recording, the routing-pattern audit result, and the rollback test result. ## Reusable existing issues, PRs, and primitives #600 and #605 — referenced, superseded in behaviour, not retracted. The existing allocator dry-run path as the basis for a read-only compatibility invocation. ## Fundamental-workflow stage supported inspect -> choose entry conditions — charter steps 1 and 5, plus What this project is not and the Responsibilities dispatcher guardrail.

Sign in to join this conversation.

Branches Tags

master

fix/issue-987-native-mcp-bootstrap

feat/issue-985-project-scoped-launcher-identity

fix/issue-983-cross-repo-base-ref

feat/issue-980-stale-worker-retirement

fix/issue-975-client-identity-heartbeat

fix/issue-973-cross-repo-canonical-roots

fix/issue-970-safely-resolve-missing-worktrees

fix/issue-969-native-mcp-bootstrap

feat/issue-664-break-glass-restart

feat/issue-708-mcp-namespace-attachment

feat/issue-665-restart-audit

fix/issue-700-durable-walls

fix/issue-704-prevent-env-workspace-bindings

feat/issue-707-cross-project-boundaries

fix/issue-690-review-profile-switch-guard

fix/issue-953-bootstrap-lock-provenance

feat/issue-949-native-fleet-inventory

fix/issue-943-runtime-context-helpers

fix/issue-945-owning-pr-renewal-evidence

fix/issue-941-scope-guard-bootstrap-wiring

docs/issue-930-remote-mcp-coupling-inventory

fix/issue-892-author-bootstrap-deadlock

fix/issue-686-detect-reject-manual-mcp

fix/issue-672-mcp-config-drift

fix/issue-689-deterministic-mcp-namespace

feat/issue-666-concurrent-mcp-restart-tests

feat/issue-659-maintenance-drain-mode

feat/issue-648-notifications-console

fix/issue-670-direct-master-incident

feat/issue-644-console-recovery

feat/issue-650-providers-insights

feat/issue-669-scoped-component-recovery

docs/issue-668-mcp-ha-rolling-restart

feat/issue-667-console-restart-controls

feat/issue-645-linkage-console

feat/issue-643-request-preview-initiate

fix/issue-897-permission-stale-runtime-classification

feat/issue-641-runtime-session-view

feat/issue-663-restart-classes

feat/issue-661-drain-proof-hard-gate

fix/issue-854-semantic-container-exclusion

issue-640

fix/issue-682-starlette-httpx2

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

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