workers integration: feedback stats structurally unreachable (recordAgentPerformance has no call sites, profiles never persisted); Total Agents is a 6-entry internal table

Summary

workers integration renders honestly — it prints zeros rather than inventing activity. But three of its four statistics are structurally unreachable: the code path that would populate them has no call sites, and its backing store has no persistence. The fourth is a hardcoded internal table size, not the user's agent count.

Measured on 2.1.2. (Absent on @alpha — see #208 §3.)

---

Observed

$ agentic-flow workers integration

⚡ Worker-Agent Integration Stats
════════════════════════════════════════
Total Agents:       6
Tracked Agents:     0
Total Feedback:     0
Avg Quality Score:  0.00

Model Cache Stats
────────────────────
Hits:     0
Misses:   0
Hit Rate: 0.0%

I tried to move the numbers before concluding anything — workers dispatch "analyze security vulnerabilities…", workers native security, workers agents security-scan, then re-read in a fresh process. Byte-identical, "agentMetrics": [].

---

1. trackedAgents / totalFeedback / avgQualityScore can never be non-zero

All three are derived in getStats() (dist/workers/worker-agent-integration.js:438-449) from agentPerformanceProfiles:

const profiles = Array.from(agentPerformanceProfiles.values());
const totalExecutions = profiles.reduce((sum, p) => sum + p.executionCount, 0);
...
trackedAgents: profiles.length,
totalFeedback: totalExecutions,

Two independent reasons that Map is always empty here:

(a) Nothing ever writes to it. The only writer is recordFeedback() (line 286) via its public wrapper recordAgentPerformance() (line 465). Grepping all of dist/ for recordAgentPerformance returns exactly four hits — the definition itself, an index.js re-export, and two .d.ts declarations. No call sites. No worker, phase, dispatch path, or hook invokes it.

(b) It would not survive the process anyway. agentPerformanceProfiles is a module-level new Map() (line 172) with no serialization — no readFile/writeFile in the module. The CLI is one-shot per process, so even a populated Map would be gone before the next command.

This is the same root cause as the in-memory worker registry in #182: a genuine implementation whose state can never be observed through the CLI.

Either wire recordAgentPerformance into the worker execution path and persist the profiles, or mark these fields as not-yet-implemented so they aren't read as "no activity yet".

2. Model cache Hits/Misses are 0/0 for the same reason

modelCache is likewise per-process, and getStats() reads it in a fresh process before anything has loaded a model. Compounding it, the bundled ruvector-onnx-embeddings-wasm@0.1.2 cannot be loaded at all (ReferenceError: module is not defined in ES module scope — #208 §2), so a miss could never become a hit even within one process.

3. Total Agents: 6 is a hardcoded internal table, not the agent count

totalAgents: AGENT_CAPABILITIES.size,

AGENT_CAPABILITIES (line 14) has six entries: researcher, coder, tester, security-analyst, performance-analyzer, documenter. The package itself ships 63 agents (agentic-flow --list). Under a heading reading "Total Agents", 6 is misleading — it is the size of the worker-integration capability map.

4. Documented output is not reachable

The docs show:

Total Agents:       66
Tracked Agents:     45
Total Feedback:     1,247
Avg Quality Score:  0.89
Hits: 12,456 | Misses: 234 | Hit Rate: 98.2%

66 matches neither the capability table (6) nor the shipped agents (63), and per §1–§2 no code path in the package can produce a non-zero value for any of the other five figures.

---

What is right

The command does not fabricate. Faced with an empty store it prints zeros and an empty agentMetrics array — the same discipline workers status shows with No workers found, and the opposite of workers cleanup's hardcoded 1 (#182). The defect is the dead write path, not the reporting layer.

Environment

agentic-flow 2.1.2 (global), Node 24, macOS 15.6, run in an empty scratch directory.

Start in dist/workers/worker-agent-integration.js around the module-level Map, recordFeedback/recordAgentPerformance, getStats(), and AGENT_CAPABILITIES. Trace the workers CLI execution paths and compare the observed output with the documented statistics; done means the reported agent and feedback metrics have an intentional, reachable state source, or are explicitly marked unimplemented, and Total Agents is not misleading.