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.

The project implements no cryptography of its own and chooses no algorithms: a search of the taken package found no cryptographic code beyond the TLS configuration in taken/transport.py. All algorithm selection happens inside the platform TLS stacks of the gh CLI and httpx, which are maintained and updated independently of this project, so there is no project-chosen algorithm that would need an agility mechanism.

The project stores no credentials, so there is no project-managed credential that would be hard to change: authentication is delegated to the gh CLI's own credential store, or to the GH_TOKEN and GITHUB_TOKEN environment variables used by the transport layer. ARCHITECTURE.md documents that the one exception, the persistent session transport, holds the token in memory only and never on disk or in logs, so a credential can be revoked or replaced in gh or in the environment with no change to the project.

Every network call the tool makes goes over HTTPS. taken/transport.py defines its API_BASE and GRAPHQL_URL constants as https://api.github.com endpoints, and the default transport shells out to gh api, which also speaks HTTPS to the same host. No plaintext HTTP endpoint appears anywhere in the package.

Nothing in the taken package configures or downgrades TLS protocol versions; the only TLS-related code is in taken/transport.py, which selects a CA bundle and never touches protocol settings. Connections are made by the gh CLI and by httpx using their platform TLS stacks at secure defaults, which negotiate TLS 1.2 or higher with api.github.com.

In taken/transport.py, the _verify_arg() helper returns either an explicit CA bundle path taken from SSL_CERT_FILE, REQUESTS_CA_BUNDLE, or CURL_CA_BUNDLE, or True, which keeps httpx and certifi certificate verification fully enabled; it never returns False, so verification cannot be switched off by configuration. The default subprocess transport delegates TLS to the gh CLI, and taken/graphql.py documents that its persistent sessions negotiate TLS end to end, including through a proxy tunnel.

The tool sends its Authorization header, which is private information, only on TLS connections where certificate verification is in force. In taken/transport.py, the _verify_arg() helper returns an explicit CA bundle path or True and never returns False, so the httpx transport verifies certificates before any header is sent. The default subprocess transport delegates the connection to the gh CLI, which verifies certificates the same way. This is the same evidence as the crypto_certificate_verification answer, applied to the private-header case.

taken/checks.py validates the shape of GitHub API responses before use and raises TakenError when a payload has an unexpected shape, as in the isinstance guards around the API helpers and the comment scan, so malformed data fails closed instead of being trusted. Inputs from the user are validated as well: an unparseable target exits with code 3, as documented in README.md and asserted by the CI smoke test, and the git history records a fix rejecting out-of-range numeric inputs.

The hardening mechanisms named in the criterion do not apply to this software: it ships no compiled code, so there are no compiler mitigation flags to set, and it operates no web service, so there are no HTTP response headers for the project to emit (the documentation site is static hosting on GitHub Pages). Where the project does control an execution environment, the CI workflow already runs with a least-privilege token (permissions: contents: read in .github/workflows/ci.yml) and SHA-pinned actions.

CodeQL's Python security-and-quality query suite covers common vulnerability patterns.