docker-devkit 0.1.0__tar.gz

docker_devkit-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,33 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v5
+
+      - uses: astral-sh/setup-uv@v7
+        with:
+          enable-cache: true
+
+      - name: Lint
+        run: uv run ruff check .
+
+      - name: Format
+        run: uv run ruff format --check .
+
+      - name: Type check
+        run: uv run basedpyright
+
+      - name: Test
+        run: uv run pytest

docker_devkit-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,25 @@
+name: Release
+
+on:
+  workflow_run:
+    workflows: [CI]
+    types: [completed]
+    branches: [main]
+
+jobs:
+  publish:
+    if: github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.event == 'push' && github.event.workflow_run.head_branch == 'main'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      id-token: write
+    steps:
+      - uses: actions/checkout@v5
+
+      # Workaround: fetch-tags is broken with shallow clones
+      - run: git fetch --tags origin
+
+      - uses: astral-sh/setup-uv@v7
+
+      - name: Publish
+        run: uvx --from release-kit==0.1.0 publish-packages --config publish-config.json

docker_devkit-0.1.0/.gitignore

@@ -0,0 +1,12 @@
+**/__pycache__
+**/*.pyc
+**/*.pyo
+**/*.pyd
+**/.venv/
+**/*.egg-info
+**/build/
+dist/
+.pytest_cache
+.ruff_cache
+.env
+bookmark.md

docker_devkit-0.1.0/.python-version

@@ -0,0 +1 @@
+3.13

docker_devkit-0.1.0/AGENTS.md

@@ -0,0 +1,59 @@
+# docker-devkit
+
+## What this is
+
+`docker-devkit` owns the Docker-stack lifecycle commands — `up`, `down`, `build` — plus the helpers they share (`detect_gpu`, `modes`, `context_sha`). It is a small, generic package that any repo shipping a compose graph can depend on to get the same bring-up/tear-down / cross-build flow, with a native/consumer split so a repo that authors its own images and a repo that only OCI-includes an upstream artifact both work through the same commands.
+
+The package is `docker_devkit` (src-layout under `src/docker_devkit/`); all dependencies resolve from PyPI (`bashrun>=0.1.0`; git-source pins only in scratch branches testing unreleased changes). The repo and package renamed twice on the way here — `stack-lifecycle` → `stack-toolkit` (2026-09-20, before any publish) and `stack-toolkit` → `docker-devkit` (2026-09-21, member of the `-devkit` family). The PyPI identity is fresh: `docker-devkit` starts its own tag ledger at `0.1.0`; the terminal `stack-toolkit` distributions (≤0.1.1) are deprecation signposts pointing here, not this package's history.
+
+## Release flow
+
+Publishing rides `release.yml`, triggered by a successful CI run on a `main` push: the machinery — release-kit, invoked uvx-isolated, never a project dependency (docker-devkit sits inside its own dependency graph; a project-level release-kit edge is a resolver cycle) — computes the plan from the tag ledger and path-diff, patches the version ephemerally, and publishes to PyPI under OIDC trusted publishing (publisher bound to `release.yml`, no environment). The committed `pyproject.toml` version is permanently the `0.0.0.dev0` sentinel; the `docker-devkit-v*` tags are the version ledger (first release `0.1.0`, patch-auto thereafter). API-breaking changes ship with a manually bumped version — patch-auto assumes additive changes.
+
+## Shape
+
+Entry points (`[project.scripts]`): `up` → `up.py:app`, `down` → `down.py:app`, `build` → `build_docker.py:app`. All accept `--help`.
+
+| Module | Role |
+|---|---|
+| `up.py` | `docker compose up`. Flags: `--attached`/`-a`, `--quiet-pull`/`-q`, `--build`, `--gpu auto\|cuda\|rocm\|none`, `--no-dev`, `--compose-file`. |
+| `down.py` | `docker compose down`. Flags: `--volumes`/`-v` (also removes named volumes), `--gpu`, `--compose-file`. |
+| `build_docker.py` | `run_build()` + the `build` command — cross-builds all images per `compose.bake.yml`, writes `.env.lock` (third-party pulled digests) and `.env.shas` (locally-built `tree-<hash>` tags). |
+| `detect_gpu.py` | `detect_gpu()` → `cuda`/`rocm`/`none` from host devices; the `Gpu` literal. |
+| `modes.py` | `resolve_auth_mode()` — validates `PUBLIC_URL` + `AUTH_MODE` from `.env`, rejecting `keycloak` over cleartext `http://`. |
+| `context_sha.py` | `compute_service_shas()` — per-service `tree-<hash>` image tags over the `.dockerignore`-allowlisted git tree. |
+| `image_refs.py` | Image-reference collection — `collect_repo_references(root, …globs)` enumerates every reference across compose `x-image-ref` services, bake `x-base-images` (pydantic-validated), Dockerfile `FROM`, Dockerfile `COPY --from=` (slash-bearing captures only, so build-stage names are skipped), and yaml `image:` line scans; the Dockerfile and yaml globs are `None`-able to skip those sources (consumer mirroring scans declarations only, policing scans everything); plus build-arg stripping, `unpinned_references(root)` (every slash-bearing reference must carry a tag, a digest, or a trailing `${build-arg}` suffix — consumer CIs fail on its result), `version_coupling_violations(root, couplings)` (each `VersionCoupling` names a pyproject-declared version and the `VersionSite` regexes that must restate it — bake `x-base-images` values or raw file text — so non-derivable couplings like uv `required-version` ↔ uv-base-image tag can't drift silently; the mechanism lives here, the registry in consumer repos' preflight), and remote digest resolution via `imagetools inspect`. `run_build()` consumes the two structural collectors; consumer repos' mirroring tooling consumes the repo scan. |
+
+## Constraints
+
+### Native stack vs. consumer stack
+
+**Context.** A repo that authors its own stack builds its own images and assembles a multi-file compose graph (`compose.yml` + `compose.postgres.yml` + a GPU layer + `compose.dev.yml`), injecting per-service `${*_SHA}` image tags and a `.env.lock` of third-party digests. A consumer repo has none of that: it ships a single self-contained compose file that OCI-includes the upstream artifact already baked (image digests and internal vars frozen as literals) or includes a sibling checkout (which supplies its own `.env.lock`/`.env.shas` through the include's `env_file`). Running `compute_service_shas` there is meaningless (no `compose.bake.yml`, no Dockerfiles) and requiring `.env.lock` is wrong (the consumer has no internal vars to resolve).
+
+**Constraint.** `up`/`down` pick the mode by the marker `compose.bake.yml`. **Native** = the default `--compose-file compose.yml` *and* `compose.bake.yml` present → multi-file assembly, SHA injection, `.env.lock` required. **Consumer** = anything else → the single `--compose-file` is the whole graph, run with `--env-file .env` alone; SHA resolution is skipped and `.env.lock` is passed only if it happens to exist. `--build` is rejected outside native mode (a consumer has no local build graph).
+
+**Consequences.** A consumer runs `uv run up` (default `compose.yml`) or `uv run up --compose-file compose.local.yml` from its own repo root, against its own `.env`, with no extra setup. A native stack's behavior is unchanged: default `compose.yml` stays native, and an explicit non-default `--compose-file` still falls through to the single-graph path.
+
+### File and env conventions the commands assume
+
+- `.env` (required) — carries `PUBLIC_URL` and `AUTH_MODE`; `modes.py` reads it and rejects `keycloak` over cleartext `http://`.
+- `.env.lock` (native, required, checked in) — third-party and base-image digests, written by `build`. `up`/`down` refuse to run natively without it.
+- `.env.shas` (native, gitignored, per-build) — `tree-<hash>` tags of locally-built images, written by `build`. `up` injects the `${*_SHA}` values into the environment directly (native mode only) and reads neither file; `.env.shas` exists so a consumer running the compose files through raw `docker compose` can resolve those holes via `--env-file .env.shas`.
+- `compose.bake.yml` (native, required) — the buildx-bake description; its top-level `x-cross-compile-targets` list (optional) is the set of services excluded from the default target list because they need per-arch treatment, opt-in via `--targets`.
+- `compose.yml` / `compose.postgres.yml` / `compose.<gpu>.yml` / `compose.dev.yml` — native's multi-file layers; the GPU one is picked by `detect_gpu()` (or the `--gpu` override).
+- `.dockerignore` (native) — allowlist that `context_sha.py` hashes over to compute per-service `tree-<hash>` tags. See "Docker build context" in `AGENTS-SHARED.md` for the allowlist rationale.
+
+The build command writes to two files rather than one because a CI invariant forbids built-image digests in `.env.lock` (which is committed and reviewed) and because `.env.shas` changes on every source edit, so it stays out of version control.
+
+### Package split rationale
+
+Lifecycle (`up`/`down`/`build`) and codegen (client generation, datamodel generation, workspace locking) have disjoint dependency surfaces. Bundling them would force a consumer that only brings a stack up to install `sqlacodegen`, `psycopg`, `datamodel-code-generator`. Keeping the lifecycle in its own small package lets consumers git-reference just this without dragging the codegen surface behind it.
+
+### `--quiet-pull` logging and GPU auto-detection
+
+`--quiet-pull` suppresses compose's per-layer progress (CUDA images carry hundreds of layers) while still surfacing pull totals. `--gpu auto` resolves to `cuda`/`rocm`/`none` from host devices and selects the matching `compose.<gpu>.yml`; override only to reproduce a CI environment or test the CPU-only path.
+
+## See also
+
+- `README.md` — human-facing setup and usage.
+- [`bashrun`](https://github.com/outernet-foundation/bashrun) — the guardrailed subprocess wrapper the lifecycle commands shell out through.

docker_devkit-0.1.0/CLAUDE.md

@@ -0,0 +1 @@
+@AGENTS.md

docker_devkit-0.1.0/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1.  Definitions.
+
+    "License" shall mean the terms and conditions for use, reproduction,
+    and distribution as defined by Sections 1 through 9 of this document.
+
+    "Licensor" shall mean the copyright owner or entity authorized by
+    the copyright owner that is granting the License.
+
+    "Legal Entity" shall mean the union of the acting entity and all
+    other entities that control, are controlled by, or are under common
+    control with that entity. For the purposes of this definition,
+    "control" means (i) the power, direct or indirect, to cause the
+    direction or management of such entity, whether by contract or
+    otherwise, or (ii) ownership of fifty percent (50%) or more of the
+    outstanding shares, or (iii) beneficial ownership of such entity.
+
+    "You" (or "Your") shall mean an individual or Legal Entity
+    exercising permissions granted by this License.
+
+    "Source" form shall mean the preferred form for making modifications,
+    including but not limited to software source code, documentation
+    source, and configuration files.
+
+    "Object" form shall mean any form resulting from mechanical
+    transformation or translation of a Source form, including but
+    not limited to compiled object code, generated documentation,
+    and conversions to other media types.
+
+    "Work" shall mean the work of authorship, whether in Source or
+    Object form, made available under the License, as indicated by a
+    copyright notice that is included in or attached to the work
+    (an example is provided in the Appendix below).
+
+    "Derivative Works" shall mean any work, whether in Source or Object
+    form, that is based on (or derived from) the Work and for which the
+    editorial revisions, annotations, elaborations, or other modifications
+    represent, as a whole, an original work of authorship. For the purposes
+    of this License, Derivative Works shall not include works that remain
+    separable from, or merely link (or bind by name) to the interfaces of,
+    the Work and Derivative Works thereof.
+
+    "Contribution" shall mean any work of authorship, including
+    the original version of the Work and any modifications or additions
+    to that Work or Derivative Works thereof, that is intentionally
+    submitted to Licensor for inclusion in the Work by the copyright owner
+    or by an individual or Legal Entity authorized to submit on behalf of
+    the copyright owner. For the purposes of this definition, "submitted"
+    means any form of electronic, verbal, or written communication sent
+    to the Licensor or its representatives, including but not limited to
+    communication on electronic mailing lists, source code control systems,
+    and issue tracking systems that are managed by, or on behalf of, the
+    Licensor for the purpose of discussing and improving the Work, but
+    excluding communication that is conspicuously marked or otherwise
+    designated in writing by the copyright owner as "Not a Contribution."
+
+    "Contributor" shall mean Licensor and any individual or Legal Entity
+    on behalf of whom a Contribution has been received by Licensor and
+    subsequently incorporated within the Work.
+
+2.  Grant of Copyright License. Subject to the terms and conditions of
+    this License, each Contributor hereby grants to You a perpetual,
+    worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+    copyright license to reproduce, prepare Derivative Works of,
+    publicly display, publicly perform, sublicense, and distribute the
+    Work and such Derivative Works in Source or Object form.
+
+3.  Grant of Patent License. Subject to the terms and conditions of
+    this License, each Contributor hereby grants to You a perpetual,
+    worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+    (except as stated in this section) patent license to make, have made,
+    use, offer to sell, sell, import, and otherwise transfer the Work,
+    where such license applies only to those patent claims licensable
+    by such Contributor that are necessarily infringed by their
+    Contribution(s) alone or by combination of their Contribution(s)
+    with the Work to which such Contribution(s) was submitted. If You
+    institute patent litigation against any entity (including a
+    cross-claim or counterclaim in a lawsuit) alleging that the Work
+    or a Contribution incorporated within the Work constitutes direct
+    or contributory patent infringement, then any patent licenses
+    granted to You under this License for that Work shall terminate
+    as of the date such litigation is filed.
+
+4.  Redistribution. You may reproduce and distribute copies of the
+    Work or Derivative Works thereof in any medium, with or without
+    modifications, and in Source or Object form, provided that You
+    meet the following conditions:
+
+    (a) You must give any other recipients of the Work or
+    Derivative Works a copy of this License; and
+
+    (b) You must cause any modified files to carry prominent notices
+    stating that You changed the files; and
+
+    (c) You must retain, in the Source form of any Derivative Works
+    that You distribute, all copyright, patent, trademark, and
+    attribution notices from the Source form of the Work,
+    excluding those notices that do not pertain to any part of
+    the Derivative Works; and
+
+    (d) If the Work includes a "NOTICE" text file as part of its
+    distribution, then any Derivative Works that You distribute must
+    include a readable copy of the attribution notices contained
+    within such NOTICE file, excluding those notices that do not
+    pertain to any part of the Derivative Works, in at least one
+    of the following places: within a NOTICE text file distributed
+    as part of the Derivative Works; within the Source form or
+    documentation, if provided along with the Derivative Works; or,
+    within a display generated by the Derivative Works, if and
+    wherever such third-party notices normally appear. The contents
+    of the NOTICE file are for informational purposes only and
+    do not modify the License. You may add Your own attribution
+    notices within Derivative Works that You distribute, alongside
+    or as an addendum to the NOTICE text from the Work, provided
+    that such additional attribution notices cannot be construed
+    as modifying the License.
+
+    You may add Your own copyright statement to Your modifications and
+    may provide additional or different license terms and conditions
+    for use, reproduction, or distribution of Your modifications, or
+    for any such Derivative Works as a whole, provided Your use,
+    reproduction, and distribution of the Work otherwise complies with
+    the conditions stated in this License.
+
+5.  Submission of Contributions. Unless You explicitly state otherwise,
+    any Contribution intentionally submitted for inclusion in the Work
+    by You to the Licensor shall be under the terms and conditions of
+    this License, without any additional terms or conditions.
+    Notwithstanding the above, nothing herein shall supersede or modify
+    the terms of any separate license agreement you may have executed
+    with Licensor regarding such Contributions.
+
+6.  Trademarks. This License does not grant permission to use the trade
+    names, trademarks, service marks, or product names of the Licensor,
+    except as required for reasonable and customary use in describing the
+    origin of the Work and reproducing the content of the NOTICE file.
+
+7.  Disclaimer of Warranty. Unless required by applicable law or
+    agreed to in writing, Licensor provides the Work (and each
+    Contributor provides its Contributions) on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+    implied, including, without limitation, any warranties or conditions
+    of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+    PARTICULAR PURPOSE. You are solely responsible for determining the
+    appropriateness of using or redistributing the Work and assume any
+    risks associated with Your exercise of permissions under this License.
+
+8.  Limitation of Liability. In no event and under no legal theory,
+    whether in tort (including negligence), contract, or otherwise,
+    unless required by applicable law (such as deliberate and grossly
+    negligent acts) or agreed to in writing, shall any Contributor be
+    liable to You for damages, including any direct, indirect, special,
+    incidental, or consequential damages of any character arising as a
+    result of this License or out of the use or inability to use the
+    Work (including but not limited to damages for loss of goodwill,
+    work stoppage, computer failure or malfunction, or any and all
+    other commercial damages or losses), even if such Contributor
+    has been advised of the possibility of such damages.
+
+9.  Accepting Warranty or Additional Liability. While redistributing
+    the Work or Derivative Works thereof, You may choose to offer,
+    and charge a fee for, acceptance of support, warranty, indemnity,
+    or other liability obligations and/or rights consistent with this
+    License. However, in accepting such obligations, You may act only
+    on Your own behalf and on Your sole responsibility, not on behalf
+    of any other Contributor, and only if You agree to indemnify,
+    defend, and hold each Contributor harmless for any liability
+    incurred by, or claims asserted against, such Contributor by reason
+    of your accepting any such warranty or additional liability.
+
+END OF TERMS AND CONDITIONS
+
+APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+Copyright [yyyy] [name of copyright owner]
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

docker_devkit-0.1.0/NOTICE

@@ -0,0 +1 @@
+Copyright 2026 Tyler Hatch

docker_devkit-0.1.0/PKG-INFO

@@ -0,0 +1,13 @@
+Metadata-Version: 2.5
+Name: docker-devkit
+Version: 0.1.0
+Summary: Docker-stack lifecycle commands (up/down/build) with a native/consumer split
+License-File: LICENSE
+License-File: NOTICE
+Requires-Python: >=3.13
+Requires-Dist: bashrun>=0.1.0
+Requires-Dist: pathspec>=1.0.4
+Requires-Dist: pydantic-settings>=2.9.1
+Requires-Dist: pydantic>=2.11.7
+Requires-Dist: pyyaml>=6.0
+Requires-Dist: typer>=0.17.4

docker_devkit-0.1.0/README.md

@@ -0,0 +1,47 @@
+# docker-devkit
+
+Docker-stack lifecycle commands — `up`, `down`, `build` — with a native/consumer split. A repo that authors its own stack (Dockerfiles + `compose.bake.yml`) uses the native mode: multi-file compose assembly, per-service SHA injection, `.env.lock` resolution. A consumer repo that OCI-includes an already-baked upstream stack uses the same commands as a thin wrapper: single-graph, `.env`-only, no build path.
+
+See [`AGENTS.md`](./AGENTS.md) for the file/layout conventions the commands assume (`compose.bake.yml`, `.env.lock`, `.env.shas`, `PUBLIC_URL` / `AUTH_MODE` in `.env`) and the mode-detection contract.
+
+## Setup
+
+Requires Python 3.13+ and [uv](https://docs.astral.sh/uv/).
+
+```bash
+uv sync
+```
+
+## Usage
+
+From a stack repo's root:
+
+```bash
+uv run up                      # docker compose up (auto-detects GPU; native or consumer per compose.bake.yml)
+uv run up --build              # build images locally first (native only)
+uv run up --gpu none           # override GPU auto-detection
+uv run down                    # docker compose down
+uv run down -v                 # also remove named volumes
+uv run build                   # cross-build all images per compose.bake.yml
+uv run build --lock-only       # refresh .env.lock without building
+```
+
+## Consuming from another repo
+
+Install from PyPI and use its entry points:
+
+```toml
+[project]
+dependencies = ["docker-devkit>=0.1.0"]
+```
+
+`bashrun` resolves transitively from PyPI. To test an unreleased change, pin the repo at a git ref in a scratch branch instead (`docker-devkit = { git = "…", rev = "<sha>" }` under `[tool.uv.sources]`) and drop the pin when the release lands.
+
+## Development
+
+```bash
+uv run ruff check .
+uv run ruff format --check .
+uv run basedpyright
+uv run pytest
+```

docker_devkit-0.1.0/publish-config.json

@@ -0,0 +1,11 @@
+{
+  "packages": [
+    {
+      "name": "docker-devkit",
+      "path": ".",
+      "feeds": { "pypi": "docker-devkit" }
+    }
+  ],
+  "ci_workflow": "ci.yml",
+  "mirror_prefix": "ghcr.io/outernet-foundation/mirror"
+}

docker_devkit-0.1.0/pyproject.toml

@@ -0,0 +1,40 @@
+[project]
+name = "docker-devkit"
+version = "0.1.0"
+description = "Docker-stack lifecycle commands (up/down/build) with a native/consumer split"
+requires-python = ">=3.13"
+dependencies = [
+    "bashrun>=0.1.0",
+    "pydantic>=2.11.7",
+    "pydantic-settings>=2.9.1",
+    "typer>=0.17.4",
+    "pyyaml>=6.0",
+    "pathspec>=1.0.4",
+]
+
+[dependency-groups]
+dev = ["basedpyright>=1.39.10", "ruff>=0.14.11", "pytest>=8.0.0"]
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project.scripts]
+up = "docker_devkit.up:app"
+down = "docker_devkit.down:app"
+build = "docker_devkit.build_docker:app"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/docker_devkit"]
+include = ["src/docker_devkit/py.typed"]
+
+[tool.uv.sources]
+
+[tool.basedpyright]
+venvPath = "."
+venv = ".venv"
+typeCheckingMode = "strict"
+include = ["src", "tests"]
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]

docker_devkit-0.1.0/ruff.toml

@@ -0,0 +1,82 @@
+target-version = "py313"
+line-length = 120
+preview = true
+
+[lint]
+select = ["ALL"]
+ignore = [
+    # ── Permanent ─────────────────────────────────────────────────────────
+    # Type annotations — basedpyright strict mode handles this
+    "ANN",
+    # No docstrings, no copyright headers
+    "D",
+    "DOC",
+    "CPY",
+    # TODO/FIXME comment formatting
+    "TD",
+    "FIX",
+    # Exception message ergonomics — literal-indirection and custom-class churn without benefit
+    "EM101",
+    "EM102",
+    "TRY003",
+    # Class attribute names never conflict with builtins via self.x
+    "A003",
+    # Function-size counters — C901 already covers structural complexity
+    "PLR0911",
+    "PLR0912",
+    "PLR0913",
+    "PLR0914",
+    "PLR0915",
+    "PLR0917",
+    # Typer's Option/Argument in argument defaults is its standard API pattern
+    "B008",
+    # Boolean parameters read fine as keyword-only flags here
+    "FBT001",
+    "FBT002",
+    "FBT003",
+    # Relative imports are the intra-package convention
+    "TID252",
+    # Formatter-owned; enforced by `ruff format`
+    "COM812",
+    "I001",
+    # Magic values in comparisons are readable in this CLI
+    "PLR2004",
+    # The formatter owns wrapping; long string literals and URLs stay on one line
+    "E501",
+    # src-layout tests need no __init__.py
+    "INP001",
+    # Runtime-used typing imports stay at module level
+    "TC001",
+    "TC002",
+    "TC003",
+    # Small literal tuples read fine in membership tests
+    "PLR6201",
+
+    # ── Deferred to PLE-248 — Enforce the deferred ruff rules
+    # https://linear.app/plerionplatforms/issue/PLE-248
+    # Mirrors placeframe's root ruff.toml transitional Ticket-N blocks; lifting
+    # a rule here should happen alongside lifting it from placeframe's ruff.toml.
+    "TC006",    # move import into TYPE_CHECKING block (quoted annotation) — Ticket 1
+    "FURB113",  # use list.extend instead of repeated append — Ticket 2
+    "PLW1514",  # open/read_text without explicit encoding — Ticket 2
+    "PT001",    # @pytest.fixture over @pytest.fixture() — Ticket 2
+    "PTH111",   # os.path.expanduser → Path.expanduser — Ticket 2
+    "RUF005",   # consider spread operator instead of concatenation — Ticket 2
+    "B904",     # raise ... from inside except — Ticket 8
+    "BLE001",   # blind except Exception — Ticket 8
+    "C901",     # function too complex — Ticket 9
+    "S110",     # try/except/pass on broad exception — Ticket 9
+    "S404",     # suspicious subprocess import — Ticket 9
+    "S603",     # subprocess call with non-literal — Ticket 9
+    "S607",     # start-process-with-partial-path — Ticket 9
+
+    # ── Deferred to PLE-336 — Replace print() with structured logging
+    # https://linear.app/plerionplatforms/issue/PLE-336
+    "T201",     # print found
+]
+
+[lint.per-file-ignores]
+"tests/**" = ["S101", "S404", "S607", "PLR6301"]
+
+[lint.flake8-builtins]
+ignorelist = ["id", "map"]