v0.7.0 — first public release

v0.7.0 release notes

Paste the section below into the GitHub Release body. Everything above the line is
instructions and is not part of the notes.

Publish order matters. Register the PyPI trusted publisher first, then create the
release. Tagging first makes the publish job fail.

1. On PyPI, add a pending trusted publisher:
   • project trace-file-lineage, owner uczltw6, repository trace-file-lineage,
     workflow release.yml, environment pypi
2. In this repo, Settings → Environments → New environment → name it pypi
3. Create the release:

   git tag -a v0.7.0 -m "v0.7.0"
   git push origin v0.7.0

   then Releases → Draft a new release → choose tag v0.7.0 → paste the notes below
4. Publishing the release triggers release.yml, which checks the tag matches the
   declared version, runs twine check --strict, installs the built wheel and exercises
   it, then uploads to PyPI
5. After it lands, delete the "Not on PyPI yet" note from README.md (one paragraph
   under the quickstart) and change the install line to pip install trace-file-lineage

---

First public release

Trace File Lineage answers "where did this file come from?" for local projects — which
script, notebook, data file, command, or AI agent produced a given artifact. It reads
the files you already have. No server, no account, no API key, and no setup needed
beforehand.

pip install trace-file-lineage
lineage demo

lineage demo builds a small project, records a run, and shows the answer in under a
second.

The idea

Two kinds of answer, never mixed:

• For files you already have — the most likely origins, ranked, with the evidence
  attached. These are guesses, and they are labelled as guesses.
• For runs from now on — wrap a command with lineage run and get verified
  provenance automatically. These are proof.

A matching filename, a nearby timestamp, or a line of code that mentions a path is
never proof, and no number of them stacked together becomes proof. When the evidence
isn't there, the answer is insufficient rather than something plausible.

What you get

• lineage explain FILE — rank the likely producers and show the evidence for each
• lineage run -- CMD — record what a command changed, keeping its exit code
• lineage impact FILE / lineage stale FILE — what depends on an input, and what is
  now out of date
• lineage open — an interactive graph in your browser: click a file to focus on its
  neighbourhood, read the evidence per link, solid arrows for proof and dashed for
  guesses. One self-contained offline page.
• lineage receipt — the full manifest for a recorded run, grouped rather than dumped
• lineage doctor — what your machine can read

Where it's strongest

Python and Jupyter notebooks, whose code is genuinely parsed. Also reads Office and
OpenDocument files, PDFs, image metadata, Git rename history, and about 50 text formats
for file references.

JavaScript and TypeScript get a deliberately cautious static scan, not real language
understanding; other languages are searched rather than parsed. It suits research code,
data analysis, notebook workflows, and agent-generated artifacts — not every software
project, and it doesn't claim otherwise.

Privacy

Everything runs locally. Nothing is uploaded. Your code is never executed — it is read
and analysed. Secrets and .env files are skipped, recorded commands have
password-looking arguments stripped, and agent records keep only a summary and the
changed-file list, never prompts or conversations.

Quality

• Python 3.11–3.14 on macOS, Linux, and Windows — all twelve combinations green
• 199 tests, 83% coverage enforced in CI, plus linting and real PDF/OCR fixtures
• The explorer's JavaScript is executed in a real engine in CI on every platform
• Zero required dependencies

Known limits

Written down rather than glossed over, in
docs/limitations.md.
Short version: historical causality is sometimes genuinely unrecoverable, and the tool
says so instead of guessing.

Full changelog:
CHANGELOG.md