Dependency Inventory and Codebase Analysis

First deliverable: component registry, not a migration plan

Every directory tree likely to be touched by an agent needs: owner/team, language, build entrypoint, runtime boundary, test entrypoints, dependency manifests, CI workflow bindings, production service identifiers, generated/vendored/boilerplate classification.

GitHub mechanics: linguist-generated in .gitattributes marks generated files (also hides in diffs); dependency graph + dependency submission API give resolved-dependency picture beyond lockfiles; SBOM export as audit artifact.

Static analysis — three layers

1. Repository dependency graph — manifests, lockfiles, submitted build-time dependencies.
2. Symbol/reference graph — over Go and TS/JS modules; CodeQL (supports both Go and TS/JS, treats code as queryable data).
3. Ownership + blast-radius graph — CODEOWNERS, review history, deployment mappings, service names, on-call destinations. Dependency review enforces inspection of PRs introducing dependency changes.

Dynamic analysis

Legacy monoliths hide runtime couplings static graphs miss.

• Instrumented (or easily instrumentable) services: OpenTelemetry for Go and JS/TS — traces/metrics/logs tied back to packages and execution paths.
• Dark corners: eBPF as selective runtime probe (sandboxed kernel runtime for tracing).
• Goal is NOT call-graph completeness — just enough runtime evidence to rank migration risk, test importance, downstream impact.

Boilerplate heuristics (active vs headline LOC differ ~10×)

Score each file/package on:

• generated/vendored markers
• duplication / near-duplication
• commit churn last 6–12 months
• import centrality
• production trace presence
• test execution presence
• owner responsiveness

High-value refactoring queue = intersection of high-churn ∩ high-centrality ∩ owner-known ∩ runtime-observed ∩ test-observed.

Generated protobufs, SDK outputs, vendored libs, bundled assets, templated code: catalog but exclude from first migration waves unless the generation source itself is changing.

Canonical component record (contract between inventory layer and agent fleet)

Field	Why it matters
component_id, owner, CODEOWNER path	Routing, approvals, escalation
language/runtime	Toolchain, sandbox image, model prompts
manifests + build/test entrypoints	Affected-build calculation
direct + submitted dependencies	Blast radius, dependency review
runtime service mapping	Change risk, canary planning
question target	Stakeholder routing
generated/vendor score	Exclusion from refactor waves
confidence score	Whether agent may proceed autonomously