# ADR-001 — Pure-stdlib Python, no third-party dependencies

- **Status:** Superseded by [ADR-013](0013-dependency-vendoring-reaffirmed.md) (2026-08-29)
- **Date:** 2026-08-29
- **Deciders:** stakeholder, implementer

## Context

The add-in runs inside Fusion's embedded Python interpreter. The unrolling engine
(PRD §6) needs linear algebra, and the export layer (PRD §8) needs to write PDF and
DXF files. Both are problems with mature third-party libraries. The question is
whether to depend on any of them.

The M0 verification spike (PRD §11) established that Fusion 2704.1.53 bundles
CPython 3.14.0 whose `site-packages` contains only `README.txt` and `speedtest.py`.
`numpy`, `scipy`, `reportlab`, `ezdxf` and `PIL` all fail to import.

## Decision

Pure Python standard library. No third-party runtime dependencies and no compiled
extensions. Development tools (`pytest`, `ruff`, `mypy`, `sphinx`, `hypothesis`) are
permitted because they never ship in the add-in bundle.

## Consequences

- All linear algebra is hand-written, kept small in `core/linalg.py`.
- PDF and DXF files are authored directly (see ADR-003).
- CI targets Python 3.14 to match the runtime exactly.
- The portable core (G6) carries no dependency baggage into a future FreeCAD addon.

## Why this was superseded

The reasoning recorded here contained two factual errors, both corrected by direct
measurement in ADR-013:

1. It asserted that numpy "is not available and will not be vendored", conflating
   *infeasible* with *not worth it*. Vendoring numpy into Fusion in fact works, at
   full native speed.
2. It asserted that the performance argument for a compiled language "evaporates".
   The real figure is that numpy gives roughly 11x on the Tier E relaxation.

The **decision itself is unchanged** — ADR-013 reaffirms pure-stdlib on corrected
evidence. This ADR is superseded rather than edited because the rationale a reader
relies on must not silently change (CLAUDE.md §13).