taken

The project takes the upgrade-path arm. SECURITY.md states that security fixes are provided for the latest release, and the upgrade path is the package manager: the README documents installation with uv, pipx, pip, and npm, and each of those tools upgrades the package in place with its standard upgrade command. An upgrade needs no data migration: the tool keeps no server-side state, and its local cache is disposable and expires on its own. Older versions remain available on PyPI for anyone who must stay on one.

Issues are tracked with GitHub Issues (29 open issues). https://github.com/RogueAlg0/taken/issues

https://github.com/RogueAlg0/taken/blob/main/SECURITY.md
SECURITY.md documents the response process end to end: reports are filed through GitHub private vulnerability reporting rather than a public issue, reports are usually acknowledged within 7 days, and a confirmed report leads to a fix being prepared and released. The same file states the supported-versions policy, so a reporter can tell in advance whether their version will receive the fix.

https://github.com/RogueAlg0/taken/blob/main/CONTRIBUTING.md
CONTRIBUTING.md has a Style section that sets the project conventions in prose: keep runtime dependencies minimal, use small functions and plain names, and keep the verdict logic easy to audit. The machine-readable half of the standard lives in pyproject.toml, where the Ruff configuration fixes a line length of 100 and selects the E, F, I, W, UP, and B rule families, and the mypy configuration targets Python 3.10 with warn_unused_ignores enabled.

The CI workflow (.github/workflows/ci.yml) runs ruff check, ruff format --check, and mypy over the taken package on every push and every pull request, across Python 3.10 to 3.13, and a pull request cannot merge sensibly while those jobs fail. CONTRIBUTING.md instructs contributors to run the same commands before pushing. The tool configuration is versioned in pyproject.toml, so the enforced standard is the one recorded in the repository.

The build produces a pure-Python wheel and sdist with the hatchling backend through uv, as declared under [build-system] in pyproject.toml, and the project contains no C, C++, or other compiled code. There are no compiler or linker flags for a builder to control, so standard build variables such as CFLAGS have nothing to act on in this build.

For the same reason as the build variables criterion, the project's own build produces no compiled artifact whose debugging information could be stripped: the wheel ships Python source modules only. Nothing in pyproject.toml or in the publish workflow performs symbol stripping, because there are no symbols to strip.

The build is a single non-recursive step: pyproject.toml declares one wheel package under [tool.hatch.build.targets.wheel] (packages = ["taken"]), and uv resolves the complete dependency graph from pyproject.toml and uv.lock in one pass. There is no hierarchy of per-directory builds and no recursive make invocation anywhere in the project.

Every dependency is pinned with hashes in uv.lock, and CI installs with uv run --frozen, which fails rather than proceed if the lockfile and pyproject.toml disagree. The publish workflow builds the release artifacts from the tagged source with uv build using the same locked inputs. The project can therefore repeat a build from the same source and lockfile and obtain the same result.

Installation uses ordinary package managers at both the language and system level: the README documents uv tool install taken-gh and pipx install taken-gh from PyPI. The same release is also distributed as an npm package and as a .deb file attached to each GitHub release by the publish workflow. Uninstallation is the corresponding package-manager operation in each channel.

The project ships no installer of its own, so there is no project code that could ignore install-location variables: installation and file placement are performed entirely by the standard tools (pip, pipx, uv, npm, dpkg), each of which applies its own documented location controls. Nothing in the repository overrides or hardcodes an installation prefix.

CONTRIBUTING.md documents a short path from clone to a working development environment: uv sync installs the runtime and development dependencies from the lockfile in one command, after which the contributor runs gh auth login and uv run taken --help to confirm the setup. No manual dependency hunting, code generation, or multi-step bootstrap is involved.

https://github.com/RogueAlg0/taken/blob/main/pyproject.toml
All externally maintained components are declared in pyproject.toml following standard Python packaging conventions: three runtime dependencies (httpx, tqdm, mcp) and a development dependency group. uv identifies and resolves them from PyPI and records the exact resolved versions and hashes in uv.lock. This declaration is also what makes the one-command development setup possible.

.github/dependabot.yml configures Dependabot to check the uv (Python) and github-actions ecosystems every week and to open grouped update pull requests for anything outdated. The git history shows this operating in practice, with merged dependency update pull requests for both groups (for example the python-deps and actions bumps merged as #426 and #427). Newly disclosed dependency problems therefore surface as reviewable pull requests on a fixed cadence.

The project bundles no third-party libraries: every reused component arrives through the package manager and can be updated by regenerating uv.lock, which the weekly Dependabot configuration does automatically. The only copied code in the repository is the project's own checks, verdict, and budget modules vendored into docs/console/py for the browser console, and the docs-sync CI job fails if those copies drift from taken/, so they cannot silently go stale the way an abandoned forked library would.

The tool builds on current interfaces throughout: the GitHub REST and GraphQL APIs at their current versions, httpx for HTTP, and Python 3.10 or newer. The Ruff configuration in pyproject.toml enables the pyupgrade (UP) rule family, so CI rejects code that uses deprecated or superseded Python idioms. Dependabot proposes updates for the Python and GitHub Actions dependencies every week, which keeps the stack from aging quietly.

The CI workflow runs the automated pytest suite on every push and every pull request across Python 3.10, 3.11, 3.12, and 3.13, as defined in .github/workflows/ci.yml. A separate smoke job in the same workflow builds the wheel, installs it into a fresh virtual environment, and exercises the installed taken and taken-mcp entry points end to end, so the packaged artifact is tested as well as the source tree.

The CI workflow runs the pytest suite with coverage measurement on every push and pull request, and the coverage configuration in pyproject.toml sets fail_under = 85 so the build fails below that floor. Measured on the current code on October 13, 2026, overall statement coverage is 93.11 percent (2,845 statements), above the 80 percent level.

The mandate is written down in two places. CONTRIBUTING.md, in the Workflow section, requires contributors to make the change and add or update tests in tests/ before opening a pull request, and ARCHITECTURE.md, in its Testing section, states that new or changed decision logic needs focused coverage. pyproject.toml adds a mechanical backstop: the coverage report is configured with fail_under = 85.

CONTRIBUTING.md documents the requirement to update tests with behavior changes. https://github.com/RogueAlg0/taken/blob/main/CONTRIBUTING.md

ARCHITECTURE.md documents fail-safe defaults as a load-bearing invariant: a scan that stops early, a cache that cannot be read, or missing evidence downgrades the verdict toward CAUTION and never toward GO on thinner proof. The tool is also read-only against the GitHub API by design; CONTRIBUTING.md states it must only ever issue GET requests, so there is no write path that could bypass a check. ARCHITECTURE.md further records that the tool never sees or stores the user's token in the default transport.