mind: CTI CI standardisation Phase 5 — two tasks shipped, one in flight

[Jammy2211]

Mind state for the CTI CI standardisation Phase 5 session. Two tasks shipped and recorded, one issued with its PR open.

Completion records

complete/2026/08/arcticpy-install-standardisation.md — PyAutoHeart#170. One canonical Heart-owned arcticpy install (composite action at .github/actions/install-arcticpy, holding the single arcticpy==2.6 pin), consumed by every CTI repo, replacing four divergent shell copies. Five PRs merged: PyAutoHeart#171, autocti_workspace_test#18, autocti_assistant#22, PyAutoCTI#109, autocti_workspace#26.

The record keeps three corrections to the task's own premises, all found by building arcticpy rather than reading about it:

• The site list was wrong — PyAutoCTI has no recipe of its own (its main.yml is a thin caller of Heart's lib-tests.yml, which carries two copies), so there were four shell copies, not two.
• smoke_install.sh was not one runner-image change from breaking — Heart's smoke-tests.yml installs setuptools immediately before invoking it. The real defect was the undeclared cross-repo coupling.
• The specified recipe and assertion were both wrong: --no-deps suppresses arcticpy's runtime imports (scipy, matplotlib) so import arcticpy fails without them; and arcticpy exposes no __version__ attribute, so the specified assertion raises AttributeError on a healthy install — a broken command that was already shipped in the assistant's setup skill.

Plus the measured answer to the caching question (the compile is ~14 s of a ~52 s step — don't cache) and the reproduced negative case (a fresh Python 3.12 venv ships no setuptools; the build then dies at BackendUnavailable).

complete/2026/08/wiki-currency-baseline-drift.md — autocti_assistant#24, PR #23 merged. wiki-currency was red on main independently of any PR. The drift-report artifact's blob host is blocked by this session's network policy, so the run was reproduced locally to find the single failing sub-check (--check-version, on the autoarray and autofit API-surface hashes).

Proved it was staleness rather than a stale doc claim by diffing the public symbol sets at the baseline's own commits (PyAutoFit daa4e39, PyAutoArray 85c57eb) against today's main. Two symbols were removed, so the drift was not blindly additive — but neither is cited, all 31 cited symbols resolve, and the autonerves/autocti/autocti.plot hashes were byte-identical.

The record also keeps the finding that the report was lying about what it installed (stack_version: latest released when the native path builds from main source clones) — the mislabel that sent the original diagnosis to the wrong hypothesis — and recommends against the task's suggested remedy of pinning to a released stack version.

Issued, in flight

active/phase5_smoke_reenable_ordered_trap_scripts.md → autocti_workspace#27, PR #28 open.

The task's premise did not hold: autocti_workspace has no smoke_tests.txt and never had one — no .github/, no config/build/, nothing deleted in history. So it creates the repo's first CI rather than re-enabling coverage, which also closes pre-existing drift (Heart's config/repos.yaml already lists the repo under workspaces, whose required checks are "Smoke Tests" + "Navigator Check", with neither present).

All nine modeling/start_here.py-class scripts verified running bypassed against PyAutoFit 438f56fac. A curated three promoted (132 s cold) rather than all nine (~522 s), per the CTI repos' no-mass-promote convention; full per-script timings recorded in the workspace's AGENTS.md.

Generated files

active.md, complete/index.md, dashboard.md and dashboard.html regenerated with the repo's own tooling (lifecycle.py record/index --apply, pyauto-brain intake --apply dashboard). lifecycle.py check and index --check both OK. Merge conflicts against main on the generated pages were resolved by regeneration, never by hand.

---

Generated by Claude Code