zavage-software/app_skellington
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: spec review fixes; CLAUDE.md branch model is develop-integrates

Browse Source 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
golem
2026-10-04 20:06:40 -06:00
co-authored by Claude Opus 5.5
parent 2ce8d75326
commit ae40f57e6b
2 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CLAUDE.md
+1 -1
View File
@@ -77,4 +77,4 @@ Applications then call `invoke_from_cli()`, which parses argv and dispatches.
## Branches
`main` is the active branch. `develop` exists on the remote but is stale: it stopped in 2024-08 and still uses the old Poetry build.
`develop` is the integration branch: feature branches come off it, and PRs target it. Changes reach `main` through a `develop` → `main` PR. Release tags (`vX.Y.Z`) go on `main`. In 2026-10, `develop` was recreated from `main`; the 2024 `develop` and its PR #2 were superseded. Modernization roadmap: `docs/superpowers/specs/2026-10-04-modernization-design.md`.
docs/superpowers/specs/2026-10-04-modernization-design.md
+3 -2
View File
@@ -22,7 +22,7 @@ Keep the library's existing behaviour while modernizing the tooling and backing
## Current state (verified 2026-10-04)
- The suite passes on 3.8, 3.9, 3.10, 3.12, 3.13 and 3.14 from `main`, but it covers only `cfg` plus one CommandTree constructor smoke test. Passing it says little about CLI, DI or logging.
- `app_skellington/_version.py` is tracked, yet setuptools_scm rewrites it on every install or build. Newer setuptools_scm writes `tuple[int | str, ...]` annotations, which crash when imported on Python 3.8 and 3.9.
- `app_skellington/_version.py` is tracked, yet setuptools_scm rewrites it on every install or build, so every dev run leaves a dirty tree. (The generated file uses `from __future__ import annotations`, and running it on 3.8 was verified to work.)
- Lint isn't clean: black would reformat 2 files, isort flags 3, flake8 reports W391 and W503.
- The README names the wrong debug env var (`APPSKELLINGTON_ENABLE_LOGGING`; the code reads `APPSKELLINGTON_DEBUG`). It also claims Windows and Mac support that nothing tests.
@@ -39,6 +39,7 @@ Keep the library's existing behaviour while modernizing the tooling and backing
### PR 2: tooling (uv), packaging hygiene, docs
- `[dependency-groups] dev = ["ruff", "pytest", "pre-commit", "pyyaml"]` (PEP 735) replaces `[project.optional-dependencies] dev`, so dev tools are no longer extras on the published package. Commit `uv.lock`. uv resolves one lock across all Pythons in range, so 3.8 lanes get compatible older pytest and other tools with no hand pinning.
- Move `tests/pytest.ini` into `[tool.pytest.ini_options]` (with `testpaths = ["tests"]`), so plain `uv run pytest` from the repo root picks up the config.
- `.python-version`: set the dev default to one current version (3.14). CI covers the rest.
- **Untrack `_version.py`** and add it to `.gitignore`. setuptools_scm still generates it at build time, so the sdist and wheel ship it. Nothing in the package imports it.
- Commands become `uv sync`, `uv run pytest`, `uv run ruff ...`, `uv build` and `uv publish`.
@@ -65,7 +66,7 @@ Keep the library's existing behaviour while modernizing the tooling and backing
- Branch protection then requires only `CI / ci-ok (pull_request)`, so one required check covers every matrix lane.
- **`tests/test_ci_workflow.py`** pins the invariants: triggers, WIP gate on each PR job, matrix versions equal to the `requires-python` floor through the newest, and the `ci-ok` logic. CI drift then shows up as a red test.
- README: add "Tested on Linux, CPython 3.8–3.14 (CI). Windows/macOS: goal, untested."
- **Rollout per the playbook:** run every gate locally first, then canary one gate at a time (a lint failure, then a test failure), watch it go red, revert, watch it go green. Mathew then adds the branch-protection status check.
- **Rollout per the playbook:** run every gate locally first, then canary one gate at a time (a lint failure, then a test failure), watch it go red, revert, watch it go green. For each canary, confirm that **`CI / ci-ok (pull_request)` itself** reports failure, not just the broken lane. This proves `if: always()` and `needs.<job>.result` evaluate as expected on this act_runner, since the pattern doc never canaried them. Mathew then adds the branch-protection status check.
### Release 0.2.3 (hotfix, after PR 3 is green on `main`)