diff --git a/memory/MEMORY.md b/memory/MEMORY.md index 0e070d7a..69c9f018 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -2,6 +2,7 @@ **📌 Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** These per-maintainer distillations show what's currently in force. Raw memories below are the history; CURRENT files are the projection. (`CURRENT-aaron.md` refreshed 2026-04-25 with the Otto-281..285 substrate cluster + factory-as-superfluid framing — sections 18-22; prior refresh 2026-04-24 covered sections 13-17.) +- [**Version-currency rule covers inheriting existing repo pins, not just fresh assertions (Aaron 2026-04-27)**](feedback_version_currency_covers_inheriting_existing_pins_not_just_fresh_assertions_aaron_2026_04_27.md) — Otto-247 wake-time discipline #4 applies whenever a version pin LANDS in a new file, even when the same SHA is already pinned elsewhere in the repo. Pasting a pin into a new workflow IS asserting it's current. Verify against the upstream API's `releases/latest` (not just Web-search narrative). Caught when Otto inherited `actions/checkout@de0fac2... # v6.0.2` from `gate.yml` into a new workflow under AceHack PR #25 (pending merge) without WebSearch — pin happened to be correct, but the discipline-skip was the failure mode. - [**Block on Aaron only when he MUST act personally; weighty decisions get the same record-and-review-later flow (Aaron 2026-04-27)**](feedback_block_only_when_aaron_must_do_something_only_he_can_do_otherwise_drive_with_best_long_term_judgment_2026_04_27.md) — No "weighty=block" tier. Drive forward + bulk-align later. - [**Windows CI seed → peer-mode-agent → green Windows legs trajectory (Aaron 2026-04-27)**](project_windows_ci_peer_mode_trajectory_2026_04_27.md) — New trajectory tracked separately from CI cadence work. Stage 1 (Otto, done): Windows in per-merge matrix with `continue-on-error: true`. Stage 2 (TBD): author `tools/setup/install.ps1`. Stage 3 (peer-mode agent, blocked on peer-mode milestone): polish to green. Stage 4: flip `continue-on-error` to false. Aaron: "not rush on this." - [**CI cadence split — per-PR fast (lint + Linux build) / per-merge slow (Analyze matrix + macOS + Windows experimental) (Aaron 2026-04-27)**](feedback_ci_cadence_split_per_pr_fast_per_merge_slow_aaron_2026_04_27.md) — Slow checks (Analyze csharp + macos-26 + Windows legs) run on push-to-main / schedule / workflow_dispatch only; PR cycles drop from ~25 min to ~3-5 min. Same pattern as low-memory.yml. Windows legs `continue-on-error: true` until peer-mode agent online. diff --git a/memory/feedback_version_currency_covers_inheriting_existing_pins_not_just_fresh_assertions_aaron_2026_04_27.md b/memory/feedback_version_currency_covers_inheriting_existing_pins_not_just_fresh_assertions_aaron_2026_04_27.md new file mode 100644 index 00000000..d77dcfec --- /dev/null +++ b/memory/feedback_version_currency_covers_inheriting_existing_pins_not_just_fresh_assertions_aaron_2026_04_27.md @@ -0,0 +1,91 @@ +--- +name: Version-currency rule covers inheriting existing repo pins, not just new version numbers (Aaron 2026-04-27) +description: Aaron 2026-04-27 — Otto-247 version-currency rule (CLAUDE.md wake-time discipline #4) applies whenever a version pin LANDS in a new file, not just when proposing a fresh version number. Inheriting the existing repo pin (e.g. `actions/checkout@de0fac2... # v6.0.2`) without WebSearch-verifying it's still latest counts as the failure mode. The rule reads "search before asserting"; pasting a pin into a new workflow IS asserting it's current. +type: feedback +--- + +# Version-currency rule covers existing-pin inheritance, not just fresh assertions + +## Rule (refined from Otto-247) + +When adding any version pin to a new file — including a SHA pin +copied from another workflow in the same repo — WebSearch the +upstream's authoritative latest-release endpoint before +committing. + +The act of *landing* a pin in a new place IS asserting it is +current. "I just used what was already in `gate.yml`" does not +clear the bar; the inheriting commit re-asserts the version is +correct at land-time. + +## Why + +**Aaron's correction 2026-04-27** (autonomous-loop tick fixing +PR #25 budget-cadence workflow): + +> "checkout v4 is that the lastest make sure you search for +> latest whenever adding new versions we have some rules +> aorund that, make sure you search cause your traing data +> will be out of date" + +The Web-search Otto ran *after* the correction surfaced two +distinct things: + +1. v6.0.2 (the existing repo pin) IS the actual latest stable + release per `gh api repos/actions/checkout/releases/latest` + (published 2026-01-09). The pin was correct. +2. A Web-search top result was a stale community discussion + claiming "v6.0.2 not marked as latest" — which, if Otto + had treated as authoritative without verifying against the + API, would have led to using v6.0.1 (older). + +Both failure modes (a) skipping the search entirely and +(b) trusting stale narrative results without API verification +land in the same place: an asserted-current pin that isn't. + +## How to apply + +Workflow when adding a third-party action pin: + +1. **WebSearch upstream's release page / latest tag** — + `/` releases. +2. **Verify against the API:** + `gh api repos///releases/latest --jq '{tag_name, published_at}'` + The API answer wins over Web-search narrative. +3. **Get the SHA:** + `gh api repos///git/ref/tags/ --jq '.object.sha'` +4. **Pin format (Zeta convention):** + `/@ # vN.N.N` + (two-space gap before the trailing comment matches the + existing pins in `gate.yml`, `codeql.yml`, etc.) + +Skip-the-search is allowed only when: + +- Reviewing existing code without modifying the pin (passive read). +- The pin is already in another workflow in the repo AND the + inheriting commit doesn't substantively change the workflow + (e.g. a pure rename / move with no version-relevant edits). + Even then, prefer to verify on cadence. + +## Composes with + +- Otto-247 — the original version-currency rule (CLAUDE.md + wake-time discipline #4). +- Otto-210 — corrective on a wrong version-fact (macOS-is-free + on public repos): the same shape, "trust upstream API not + Web-search narrative." +- `.semgrep.yml` rule `gha-action-mutable-tag` — enforces + full-SHA pinning (defense-in-depth against tag-rewrite + attacks like the tj-actions/changed-files cascade + CVE-2025-30066 March 2025). Triggered on PR #25 when Otto + initially used `actions/checkout@v4`; the rule is the + factory's compile-time enforcement of the discipline this + memory captures at the human-judgment layer. + +## Pre-mortem signature for next time + +If next-Otto thinks "I'll just use the SHA already in +`gate.yml` for this new workflow," THAT is the failure mode. +The land-time assertion is what triggers the rule — search +first, then pin, even when the same SHA was already in the repo. +