Registry regen over-zeroes dependencies in non-WSL agent/task entries

[rafaelscosta]

Context

Discovered while reviewing PR #752 (cross-platform CodeRabbit). CodeRabbit flagged the broader pattern at lines 14221-14233, 14251-14272, 14384-14397, 14566-14578 in entity-registry.yaml — the change was docs-only but the regen wiped dependencies arrays for unrelated entries.

I dismissed the review claiming "phantom WSL deps", which was only partially true. Subsequent investigation (git diff 536bda9d..38cfa89f -- .aiox-core/data/entity-registry.yaml | grep -B 2 'dependencies: \[\]') shows entries like qa-create-fix-request, greenfield-ui, spec-pipeline, story-draft-checklist lost dependencies that have no semantic relation to WSL/coderabbit configuration.

Hypothesis

The regen script's dependency-extraction algorithm in .aiox-core/development/scripts/populate-entity-registry.js is sub-detecting deps for some tasks/checklists. Possible causes:

1. The dependency-extraction regex has an edge case that fails on a markdown construct in the affected files.
2. Removing wsl_config: / installation_mode: from agent personas invalidated some indirect graph edges those tasks had through the agents.
3. The recent extractPurpose rewrite (PR fix(ids): scope purpose inference + sync self-entry on regen #748) reshuffled which keys the parser walks — possibly a side-effect dropped deps along with garbage purposes.

Reproduction

git diff 536bda9d..38cfa89f -- .aiox-core/data/entity-registry.yaml \
  | grep -B 2 'dependencies: \[\]' \
  | head -40

Shows usedBy/dependencies arrays going from populated to [] for entries CodeRabbit flagged.

Severity

🟠 Major (CodeRabbit's classification). Degrades IDS impact analysis and aiox graph --deps accuracy. Not a regression of behavior, but the registry is now incomplete.

Out of scope

Not part of the cross-platform fix (#731 / #752) or the SCAN_CONFIG core-docs addition (#753). Both shipped intentionally with this drift present; this issue tracks the fix.

[rafaelscosta]

Refutation — algorithm is deterministic; transient drift was from regen against dirty working tree

Followed the audit-validation-protocol before any code changes. Verdict: not reproducible as filed; not an algorithm bug.

Sample check (issue body claims deps zeroed for these)

Entry	Issue claim	Current state in main (d877231)
qa-create-fix-request	dependencies: []	[qa-review-story, dev, qa] (3 deps)
greenfield-ui	dependencies: []	[analyst, pm, ux-design-expert, architect, po, sm, dev, qa] (8 deps)
story-draft-checklist	dependencies: []	[dev, architect, qa] (3 deps)

0/3 confirmed in main today.

Why the issue's grep gave a false positive

git diff 536bda9d..38cfa89f -- .aiox-core/data/entity-registry.yaml \
  | grep -B 2 'dependencies: \[\]'

Sample output:

-        - data-engineer
+      usedBy: []
       dependencies: []

The third line has no + or - — it's unchanged context. The -B 2 flag pulls 2 preceding lines for any dependencies: [] match, regardless of whether that line is a diff hunk. The actual mutation in this hunk was usedBy:, not dependencies:.

Authoritative net-diff (PyYAML, set-based)

Cumulative 536bda9d..main:

• 0 entries with reduced dependencies (set-diff)
• 0 entries with reduced usedBy (set-diff)
• 5 NEW entries from feat(ids): track .aiox-core/core/docs/ in entity registry SCAN_CONFIG #753 core-docs scan (4 with empty deps because their sources declare none — correct)

Determinism test 1: idempotent on main

Ran node .aiox-core/development/scripts/populate-entity-registry.js on main:

• entityCount: 820 → 820
• Deps lost: 0, added: 0
• usedBy lost: 0, added: 0

Fully deterministic.

Determinism test 2 (SMOKING GUN): regen at #752 source ≠ #752 committed registry

Checked out 38cfa89f and ran the regen against that exact source. Then compared the fresh output with what was committed in that same commit:

Fresh regen at 38cfa89f source: 815 entities
Committed in 38cfa89f:           816 entities
Entries where deps mismatch:       9

The 9 mismatches are EXACTLY:

• architect, data-engineer, dev, devops, qa (the 5 modified-by-fix(quality-gates): cross-platform CodeRabbit CLI execution [#731] #752 agents)
• dev-develop-story, environment-bootstrap, github-devops-pre-push-quality-gate, qa-review-story (the 4 tasks that reference those agents)

The fresh regen at #752 source produces the CORRECT deps. The committed registry has reduced deps.

Root cause

The registry committed in 38cfa89f was generated by a regen run against a partially-edited working tree — probably with wsl_config:/installation_mode: already stripped from some personas but other state not yet stabilized. The operator committed both the personas and the (transiently-incorrect) registry together.

PR #753 inadvertently "fixed" it because its regen ran on a clean working tree, producing correct deps for all 9 entries again.

Updated verdict

Aspect	Status
Algorithm bug in extractDependencies	NO — fully deterministic on clean source
Main today has dep regression	NO — 0 entries with reduced deps
Transient regression in #752 isolated	YES (9 entries) — but self-cured by #753
Root cause	Operator regen against partially-edited tree, not algorithm bug
Closeable?	YES

Follow-up filed

Add regen-determinism check to CI — re-run regen on every PR and fail if output diverges from committed entity-registry.yaml. Would have caught this category of drift before merge.

Local evidence: outputs/audit/2026-05-18-issue-754-refutation.md (gitignored, full reasoning).