Read workspace and local Python project architecture documentation.
Mapped ten Python projects, their package trees, path dependencies, and source-level imports.
Compared Import Linter’s intra-package and multi-root module contracts with Nx’s project-level app/lib and language boundaries.
Tested candidate layer, protected, forbidden, and independence contracts without changing the mono checkout.
Confirmed useful passing contracts for the vxData API layers and CRUD internals, SDK-to-schema direction, dashboard layers, thumbnail API layers, and VxAnnotate SDK layers.
Found two adoption caveats: the thumbnail data-source implementations are indirectly coupled through their registry in base.py, and Import Linter does not recognize the factory viseg namespace directory because it lacks __init__.py.
Lessons Learned: Pitfalls
A repository-root Import Linter configuration is a poor fit because Python projects use separate Pixi environments and several projects contribute portions of the same vxdata namespace.
Static AST summaries overcount some from ... import ... statements; running candidate contracts with Import Linter is needed for reliable dependency counts.
The Nx graph could not be generated in this worktree because JavaScript dependencies were not installed. The local Nx Pixi plugin source still establishes that only declared path dependencies create Python project edges.
Lessons Learned: Improvements
A durable workspace guide could state that architecture checks belong in each Python project’s pyproject.toml and dev environment, with cross-project contracts owned by a consumer environment that installs all roots.
Python package docs would benefit from a short dependency-direction section like the one already present in apps/vxdata-api/AGENTS.md.
