[olivermeyer]

Why?
Incident IIM-96 (eMudhra CA compromise, CVE-2026-111943) requires certifi 2026.10.19 or newer (older releases still trust the compromised roots, and 2026.10.18 is bad), pip 26.2.2 or newer and uv 0.13.4 or newer. #738 only bumped certifi in the lock, so existing environments can keep a bad certifi, and the dev container is built on Debian 11 (bullseye), which has no fixed ca-certificates.

How?
Raise the floors for certifi (runtime), pip and uv (dev, plus [tool.uv] required-version and the uv-pre-commit hook rev that mirrors it), relock with only pip moving (26.2.1 to 26.2.2), and delete .devcontainer/ with its doc and keyword references. No hotfix release is planned: the wheel declares only floors, so fresh installs already get certifi 2026.10.19, the new floor forces the upgrade in existing environments with the next normal release, and the v1.6.0 native builds have 0 downloads.

🤖 Generated with Claude Code

[ox-security]

OX Security reviewed this pull request — nothing to fix.

✔ No issues found

Branch fix/emudhra-floors → main

View scan in OX Security →

[claude]

Claude finished @olivermeyer's task in 4m 41s —— View job

---

PR Review: Security Fix for eMudhra CA Compromise ✅

Completed comprehensive review of security fix for IIM-96 (CVE-2026-111943).

---

Review Summary

This PR correctly implements the security fix with no blocking issues. ✅

Detailed Findings

✅ Security Fix Correctness

All dependency floors are correctly set to address the eMudhra CA compromise:

• certifi >=2026.10.19 (line 94, pyproject.toml) ✓
  • Comment: "IIM-96 eMudhra CA (CVE-2026-111943); older releases trust compromised roots"
• pip >=26.2.2 (line 222, pyproject.toml) ✓
  • Comment: "IIM-96 eMudhra CA (>=26.2.2)"
• uv >=0.13.4 (line 223, pyproject.toml) ✓
  • Comment: "IIM-96 eMudhra CA (>=0.13.4)"
• [tool.uv] required-version >=0.13.4 (line 229) ✓
• .pre-commit-config.yaml uv hook rev 0.13.4 (line 55) ✓
  • Comment: "GHSA-pjjw-68hj-v9mw, IIM-96; matches [tool.uv] required-version"

uv.lock verification: pip correctly bumped from 26.2.1 → 26.2.2

✅ Devcontainer Removal Completeness

All devcontainer files and references properly removed:

• Deleted files: All 5 devcontainer files removed (Dockerfile, devcontainer.json, onCreateCommand, postAttachCommand, postCreateCommand)
• OPERATIONAL_EXCELLENCE.md: Dev Containers reference removed, list items renumbered (24→27 instead of 24→28)
• SOFTWARE_ARCHITECTURE.md: Dev Containers bullet point removed from Development Environment section
• No dangling references: grep -ri "devcontainer|Codespace" returns no results ✓

✅ Code Quality Standards

• Commit messages: All 4 commits follow conventional commits format ✓

  • fix(deps): raise pip floor to 26.2.2 [IIM-96]
  • fix(deps): raise certifi floor to 2026.10.19
  • fix(deps): raise uv floor to 0.13.4 [IIM-96]
  • chore: remove the dev container setup

• Linting: All checks passed ✓

  • ruff check: All checks passed
  • ruff format: 287 files already formatted
  • pyright: 0 errors, 0 warnings, 0 informations
  • mypy: Success, no issues in 84 source files

• Test markers: No test files changed, so no marker compliance issues ✓

✅ Maintenance Mode Compliance

This PR qualifies under CLAUDE.md maintenance mode rules:

• Rule chore(deps): update actions/upload-artifact action to v4.6.2 #2: "Accept dependency updates that fix vulnerabilities" ✓
• Properly documents incident reference (IIM-96, CVE-2026-111943)
• No new features added
• Deprecation warning unchanged

✅ No Breaking Changes

The dependency floor bumps are non-breaking:

• Fresh installs already get certifi 2026.10.19 (wheels declare floors)
• Existing environments will upgrade on next pip install --upgrade aignostics
• v1.6.0 native builds have 0 downloads (minimal impact)
• No API changes, no CLI changes, no configuration changes

Rationale for Devcontainer Removal

The PR correctly removes the devcontainer setup because:

1. Debian 11 (bullseye) has no fixed ca-certificates package
2. PR chore(deps): update dependency certifi to v2026.10.19 [security] #738 only bumped certifi in the lock file, not the floor
3. Raising the floor in pyproject.toml forces the upgrade in all environments
4. No hotfix release needed (fresh installs already safe, existing envs upgrade on next release)

Suggestions (Non-blocking)

None - this PR is excellent as-is.

Praise

• Excellent documentation: The PR description clearly explains the "why" and "how"
• Comprehensive inline comments: Each dependency bump includes the incident reference
• Clean commit history: Logical separation of concerns (3 dependency bumps + devcontainer removal)
• Thorough cleanup: No dangling references to devcontainer anywhere

---

Verdict: ✅ claude:review:passed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.
see 8 files with indirect coverage changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud