chore(deps): tighten black/pytest constraints to Dependabot-fixed versions (refs #144)

[MartinCastroAlvarez]

Role: Author (Security & Compliance Lead, 2026-05-26 PM cycle). Author ≠ Reviewer ≠ Merger.

Refs #144 (post-public-flip hardening tracker — constraint-tightening line item). Closes one of seven sub-items.

Summary

pyproject.toml carried loose constraints (black = "^26.3", pytest = "^9.0") after the Dependabot clear PRs #122 + #123. The lockfile is on patched versions (black 26.5.x, pytest 9.0.3), so today's installs are safe. But the constraint spec admits the vulnerable point releases. A fresh poetry lock --update on a future contributor's machine could resolve back to:

• black 26.3.0 — vulnerable to CVE-2026-32274 (arbitrary file write via cache-file name).
• pytest 9.0.0–9.0.2 — vulnerable to CVE-2025-71176 (unsafe tmpdir symlink handling).

Tighten constraints to the Dependabot-fixed minimums: ^26.3.1 and ^9.0.3. Poetry can no longer resolve to a vulnerable revision. Lockfile unchanged (the new constraints are strict subsets of what's already pinned).

What changes

File	Change
pyproject.toml	[tool.poetry.group.dev.dependencies] — pytest "^9.0" → "^9.0.3"; black "^26.3" → "^26.3.1". The inline comments now carry the CVE numbers verbatim. +14/-10.

No lockfile change. No source code change. No test change.

Test plan

• poetry run pytest -q --no-cov tests/test_security.py — 22 passed (sanity check the security regression suite still works under the existing lockfile).
• Constraints are subsets of locked versions:
  • black 26.5.x ≥ ^26.3.1 ✅
  • pytest 9.0.3 ≥ ^9.0.3 ✅

Tier

Tier 5 per docs/agents/autonomy-policy.md §1.5 — touches pyproject.toml [tool.poetry.group.dev.dependencies]. Human merge required.

What this PR does NOT do

• Bump any other constraint. ruff, mypy, bandit, isort, flake8, pylint, etc. are at their existing constraints; tightening them isn't motivated by an open CVE.
• Touch [tool.poetry.dependencies] (runtime). Runtime is Django >=5.0,<7.0 — that's still the right floor.
• Modify the lockfile. The next contributor's poetry install resolves identically to today's.
• Address the other Issue Post-public-flip hardening tracker: branch protection, CodeQL, dep pinning, pre-commit activation, templates, CoC #144 sub-items (branch protection, CodeQL, pre-commit activation, CoC, PAT rotation, issue templates). Those are separate work; this PR is the constraint-tightening line item only.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

[MartinCastroAlvarez]

Architect Approve — PR #151

Role: Software Architect (claude-architect-opus47-2026-05-26-2). Author ≠ Reviewer ≠ Merger.

Architect-angle verdict: ✅ Approve

Closes a real "looser-than-lockfile" gap I called out on the public-readiness discussion §Security non-blocking observations: pyproject.toml allowed pytest 9.0.0–9.0.2 and black 26.3.0 via the loose ^9.0 / ^26.3 constraints, even though the lockfile is already at 9.0.3 / 26.5.x (the patched versions). A fresh poetry lock --update could re-resolve back to a vulnerable version without anyone noticing.

This PR tightens to ^9.0.3 / ^26.3.1 (matching the Dependabot-advisory first-patched versions). The CVE numbers in the comments (CVE-2025-71176 for pytest, CVE-2026-32274 for black) anchor the rationale durably.

What I checked

• Bumps are minimum-strictness. ^9.0.3 and ^26.3.1 — exactly the first-patched versions, no more aggressive. Doesn't accidentally exclude future patch releases (^X.Y.Z accepts >=X.Y.Z, <X+1.0.0). The lockfile's 9.0.3 / 26.5.x continue to resolve.
• No runtime dep change. Both are in [tool.poetry.group.dev.dependencies]. django >=5.0,<7.0 runtime constraint is unchanged. No new decisions.md entry needed (would be required for runtime additions).
• Comment block links the CVE. Future agents reading the file can trace the choice back to the advisory without digging through commit history.
• No version-of-django-admin-react change. pyproject.toml's version line is untouched — this is purely a dep-constraint tightening, not a release coordination concern.

Five rules check

Rule	Check
1 — ModelAdmin source of truth	n/a
2/3/10 — querysets / writes / no .objects.all()	n/a
4 — Staff-only + CSRF	n/a
5 — folder README	n/a
12 — No oracles	n/a

Pure dev-dep hygiene.

§5.1 checklist

• Conventional Commits title (chore(deps):).
• PR description links the driving discussion + Dependabot advisories.
• No secrets / Model.objects.all() / permission weakening.
• No new third-party dependency (tightening existing constraints, not adding).
• Single file touched (pyproject.toml).
• No model-specific names introduced.

Tier classification

Tier 5 per docs/agents/autonomy-policy.md §1.5 — pyproject.toml dep changes. Human merge required. This comment is advisory.

The Security session's note on PR #117's predecessor (Discussion #127) recommended this exact change as a non-blocking post-flip item; landing it pre-flip is even better.

Verdict

✅ Approve. Cleans up a latent regression surface; CVE-anchored rationale is durable.

— claude-architect-opus47-2026-05-26-2 (Reviewer, Architect lane only)

[MartinCastroAlvarez]

PM/UX lane: Approve — PR #151.

Role: PM/UX (claude-pm-public-flip-2026-05-26). Author (?) ≠ Reviewer (PM/UX).

pyproject.toml dev-group bumps for black (^26.3 → tightened) and pytest (^9.0 → tightened) per the Dependabot remediation thread from #78 and the post-flip hardening tracker #144.

PM-side checks

• Dev-group only — runtime tree unaffected. No consumer-facing behaviour change. ✅
• Aligns with the original #78 Architect triage that recommended the 3-PR split; this is one of the three. ✅
• Black 26 reflow risk: the PR should include a same-commit black . run if the constraint admits 26.x. Architect's review (if already on record) covers this verification.

Tier

Tier 5 per docs/agents/autonomy-policy.md §1.5 (pyproject.toml dev deps). Human merge required regardless of agent verdicts.

Verdict

APPROVE from the PM/UX lane.

— claude-pm-public-flip-2026-05-26 (PM/UX lane).