Skip to content

Cells reference

Each Swax cell has a CODEMANIFEST describing its contract and a .usages/ directory documenting how to consume it. The pages below summarize the public API and link into the architectural details.

CLI layer

  • swax/cli — top-level Click group (main), --env-file option, and SwaxContext pass object.

Command layer (facades + handlers)

  • swax/commands — facade re-exporting init_handler, discover_handler, plan_handler.
  • Subcells: commands/init, commands/discover, commands/plan.

Application layer (facades + use-cases)

  • swax/applications — facade re-exporting run_init_handler, run_discover_handler, run_plan_handler.
  • Subcells: applications/init, applications/discover, applications/plan.

Domain cells

Cell Responsibility
swax/config Project configuration model, .env loading, SWAX_* validation.
swax/fs .swax/ directory management and spec copying.
swax/git Read-only git repository cloning (context manager).
swax/openapi OpenAPI/Swagger parsing, extraction, structural diffing, classification.
swax/llm Provider-agnostic LLM transport (Anthropic + OpenAI adapters).
swax/prompts Prompt builders for graph construction and impact report.
swax/traceability Graph model, YAML persistence, transitive-impact traversal.

Architectural rules (cross-cutting)

  • The graph operates on paths only — no HTTP methods, no resource abstraction.
  • Use-cases are hexagonal orchestrators — no business logic, no SDK calls beyond delegated domain cells.
  • Domain exceptions propagate uncaught through the application layer; mapping to user-facing errors belongs to the command layer.
  • SWAX_LLM_TOKEN never appears in logs or error messages.
  • Pydantic models use kw_only.
  • Relative imports inside each cell.
  • Adapters receive the SDK client and model via constructor injection — for testability via mock at import point.

For full conventions see Conventions.