Prove TraceDecay's per-snapshot application-process integration

[BleedingDev]

Question

Which pinned TraceDecay integration can index, query, and clean up each public repository snapshot from bounded child processes spawned by the UltraModern.js application on Zerops? Establish exact CLI/JSON calls, version and distribution path, license, storage and project identity behavior, concurrency isolation, time and memory needs, cleanup, failure behavior, and the structural evidence available to normalization.

[BleedingDev]

Research dispatched.

• Branch: research/tracedecay-integration
• Temporary worktree: /tmp/codebase-radar-research.O8qi1B/worktrees/tracedecay
• Shared brief: /tmp/codebase-radar-research.O8qi1B/brief.md
• Primary report: /tmp/codebase-radar-research.O8qi1B/reports/tracedecay.md
• Branch context pointer: docs/research/tracedecay-integration.md

The branch is throwaway and will contain the report snapshot; implementation remains on main.

[BleedingDev]

Resolved by the TraceDecay integration research branch.

Pin the MIT-licensed TraceDecay v0.0.73 Linux artifact and run one app-owned, per-scan daemon child on an isolated profile, HOME, data directory, and Unix socket. Serialize TraceDecay phases, use bounded health/complexity/coupling/circular/hotspot/test-risk queries, enrich selected findings with impact/test mapping, preserve partial results, stop the daemon, and clean the exact scan root. Exclude TraceDecay redundancy for this MVP.