Skip to content

process: systemic premature-closure pattern — 7+ feature trackers closed before integration (orchestration audit evidence) #6836

Closed

Description

@mrveiss

Discovered during

User correctly pushed back during issue #4048 closure: the code I called "orphans" is not abandoned — it's completed, unit-tested, design-documented functionality whose tracker issues were closed before integration.

This is a process bug, not just individual tech debt.

Evidence

Module LOC Tracker State Wired in production?
orchestration/causal_executor.py (+ 4 sibling files) 1,722 #2154 CLOSED ❌ NO
orchestration/workflow_planner.py 282 #381 CLOSED ❌ NO
orchestration/workflow_documentation.py 390 #381 CLOSED ❌ NO
orchestration/workflow_memory.py 286 #3019 CLOSED ❌ NO
orchestration/agent_registry.py 302 #381 CLOSED ❌ NO
agents/agent_orchestration/topology.py 242 #2137 CLOSED ❌ NO
agents/agent_orchestration/topology_routing.py 94 #2138 CLOSED ❌ NO
agents/agent_orchestration/rl_router.py 354 #2092 CLOSED ❌ NO
enhanced_orchestration/success_criteria.py 234 #3293 CLOSED ⚠️ single test caller
Total unwired 3,906

Each docstring explicitly cites a tracker issue. Each tracker is marked closed. None of the corresponding code is reachable from a production request path.

Plus #3228 (graph executor unification) — also CLOSED while code comments still reference it as "tracked in #3228" for unfinished work — see #6826.

Pattern

Issues are being closed when code is written and unit-tested, not when acceptance criteria for integration are met. The CLAUDE.md "Issue Closure Verification Gate (MANDATORY)" rule exists exactly to prevent this:

Verify each acceptance criterion: Is the feature/fix actually implemented? Does it work correctly?

"Working correctly" requires reaching production code, not just test code.

Why it matters

  • ~3,900 LOC of unused completed features sit in the tree, contributing to god-class metrics, increasing build time, confusing readers about what's canonical
  • Stakeholders who closed those issues think the features shipped — they didn't
  • The original goals of the issues (e.g., "shared memory between parallel workflow agents" enhancement: no shared memory between parallel workflow agents #3019) are not actually delivered to users

Recommendation

Process changes

  1. Add an "integrated" acceptance criterion as a default in CLAUDE.md "Issue Closure Verification Gate":

    Closure requires: (a) code merged, (b) at least one production code path imports the new module, (c) integration test exists.

  2. Closure audit: when closing a feature issue, run grep -rn 'from <new_module>' autobot-backend --include="*.py" | grep -v _test — must return ≥1 hit.

Tactical follow-up

  1. Reopen trackers Enhancement: Q-Learning reinforcement router for agent task routing #2092, feat: Agent mesh topology — dynamic DAG with Hebbian evolution (Neural Mesh RAG Phase 5) #2137, feat: Topology-aware routing + agent specialization (Neural Mesh RAG Phase 5) #2138, Enhancement: Workflow resume-from-failure and step-level error handlers #2154, enhancement: no shared memory between parallel workflow agents #3019, feat(backend): custom success criteria definitions for workflow orchestrator #3293, plus Code Smell: Refactor 178 god class patterns #381 sub-trackers — none meet integration acceptance criteria.
  2. The 14 follow-up issues from refactor(backend): complete orchestrator consolidation (7→4 target) #4048 closure (discovery(orchestration): wire in or retire abandoned causal subsystem (5 files, 1,722 LOC, 0 production callers) #6816–discovery(orchestration): subagent_dispatcher.py is test-only, lives in services/ instead of orchestration/ (layering violation) #6822, discovery(orchestration): #3228 closed prematurely — executor fragmentation persists (5 files, 3,223 LOC, no unified strategy) #6826–discovery(orchestration): low-utilization composability — SuccessCriteriaEvaluator + CollaborationCoordinator are single-caller modules #6832) collectively represent the wire-in work. They are the path to making each reopened tracker actually deliverable.

Acceptance criteria

Priority

P1 — process correction. Blocks credibility of "closed" issue counts as a measure of delivered features.

Activity

  1. mrveiss commented on May 4, 2026

    @mrveiss
    OwnerAuthor

    ✅ Closed with proof — PR #6875 merged in commit f118ace17

    Implementation acceptance criteria:

    Integration acceptance criteria (#6836 gate):

    • ✅ Audit script reachable via python3 pipeline-scripts/audit-unwired-trackers.py --json — entry point wired
    • ✅ Workflow file at .github/workflows/unwired-tracker-audit.yml — discoverable by GitHub Actions
    • ✅ CLAUDE.md gate referenced from feature template, both /implement and /issue skills, and /dead-code-audit Phase 0
    • ✅ Closure gate dogfooded on this very issue — closure comment lists both implementation and integration ACs separately

    The pattern is now prevented at four layers: (1) feature template surfaces the integration AC at issue creation, (2) skills run a grep at closure time and block on zero callers, (3) cron runs weekly to catch anything that slips, (4) future dashboard (#6871) for visibility. Retroactive sweep tracked as #6872.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions