memory(version-currency): inheriting existing pins counts as fresh assertion (rebased from #656)

[AceHack]

Summary

Aaron 2026-04-27: Otto-247 wake-time discipline #4 (CLAUDE.md
version-currency rule) applies whenever a version pin LANDS in a
new file, NOT just when proposing a fresh version number.

Rebased from PR #656 (acehack/memory/version-currency-inherit-pins-lesson-2026-04-27).
The original PR's 4-commit branch had stale-base MEMORY.md conflicts
on each commit; clean-extracting from branch-tip avoided the
rebase-conflict-cascade per the 5-pre-flight-disciplines lesson.

Composes with:

• Otto-247 (CLAUDE.md wake-time discipline Round 28 — FsCheck LawRunner (Option B) + round-29 CI anchor #4)
• The B-0083 supply-chain SHA256-pin guidance (just landed via backlog + substrate(2026-04-28): B-0083 Atari ROM tooling + B-0084 CodeQL verify + 2 trajectory memories + absorb-contribute end-goal #680)
• The 5-pre-flight-disciplines memory (history preservation)

PR #656 will be closed-as-superseded by this PR after merge.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a new durable memory clarifying that the CLAUDE.md version-currency discipline applies when copying existing version pins into a new file (i.e., inheriting a pin is still a fresh assertion of currency), and updates the memory index accordingly.

Changes:

• Add a new memory entry documenting the “inherited pins still require currency verification” refinement to Otto-247.
• Prepend a corresponding index entry in memory/MEMORY.md.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
memory/feedback_version_currency_covers_inheriting_existing_pins_not_just_fresh_assertions_aaron_2026_04_27.md	New memory documenting the refined version-currency rule and an application workflow for action pin verification.
memory/MEMORY.md	Adds a newest-first index link to the new memory entry.

[Copilot]

The suggested command to “Get the SHA” via .../git/ref/tags/<vN.N.N> --jq '.object.sha' is not reliable: for annotated tags it returns the tag-object SHA, not the commit SHA needed for uses: owner/repo@<sha> pins (and can break checkouts). Prefer resolving the tag to a commit SHA (e.g., via the commits endpoint for the tag, or by dereferencing tag objects when .object.type == "tag").

Suggested change

	3. **Get the SHA:**
	`gh api repos/<owner>/<repo>/git/ref/tags/<vN.N.N> --jq '.object.sha'`
	3. **Get the commit SHA (not the tag-object SHA):**
	``TAG_JSON=$(gh api repos/<owner>/<repo>/git/ref/tags/<vN.N.N>) &&
	TAG_TYPE=$(printf '%s' "$TAG_JSON" | jq -r '.object.type') &&
	TAG_SHA=$(printf '%s' "$TAG_JSON" | jq -r '.object.sha') &&
	if [ "$TAG_TYPE" = "tag" ]; then
	gh api repos/<owner>/<repo>/git/tags/"$TAG_SHA" --jq '.object.sha'
	else
	printf '%s\n' "$TAG_SHA"
	fi``

[Copilot]

This note claims the two-space gap before the trailing # vN.N.N comment “matches the existing pins in gate.yml, codeql.yml, etc.”, but the repo is inconsistent (e.g., gate.yml uses a single space while codeql.yml uses two). Please either avoid asserting a repo-wide spacing convention here, or align the claim to the actual current state (and/or point at a single canonical example).

Suggested change

	(two-space gap before the trailing comment matches the
	existing pins in `gate.yml`, `codeql.yml`, etc.)
	(include the trailing `# vN.N.N` comment after the SHA.)

[Copilot]

The term is used inconsistently as “Web-search” here, but elsewhere (e.g., CLAUDE.md) the tool name is consistently WebSearch. To avoid confusion between the tool name and generic “web search”, please standardize these occurrences (either use WebSearch in code spans when referring to the tool, or plain “web search” when not).