[Planeshifter]

Resolves stdlib-js/todo#2682.

Description

What is the purpose of this pull request?

This pull request:

• adds a Git note (type: amend-message) for commit e3ff363, whose message referred to the removed namespace symbol by the package name `any-own-by` instead of the symbol name `anyOwnBy` (in the subject, body, and BREAKING CHANGE line)
• adds a Git note (type: amend-message) for commit c04a8bc, whose message contained the typo `@stdlib/objects/any-own-by` instead of `@stdlib/object/any-own-by` in the migration instructions

Both corrected messages are taken verbatim from the maintainer's review comments on the original pull request:

• feat: migrate utils/any-own-by to object/any-own-by #8658 (comment)
• feat: migrate utils/any-own-by to object/any-own-by #8658 (comment)

The note files follow the exact format produced by the git_note_amend_message.yml workflow and consumed by make apply-git-notes and the changelog tooling.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• stdlib-js/todo#2682
• feat: migrate utils/any-own-by to object/any-own-by #8658 (the pull request whose merged commit messages are amended)
• [RFC]: migrate utils/any-own-by to object/any-own-by #6756 (the migration issue referenced by the amended commits)

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

• The amended commits are the rebase-merged copies on develop (committer date equal to PR feat: migrate utils/any-own-by to object/any-own-by #8658's merge time), not the pre-rebase pull-request branch SHAs.
• Verified that git notes add -f -F <file> <hash> (the exact command run by make apply-git-notes) applies both notes cleanly, and that the changelog parser's front-matter extraction yields exactly the corrected messages. A diff of original vs. amended messages shows only the intended corrections (three lines in the first commit, one line in the second).

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

This PR was authored entirely by Claude Code, run as a scheduled automation on behalf of Philipp Burckhardt: it identified the target commits on develop, created the note files from the maintainer's corrected messages verbatim, and verified format and applicability against the repository's Git-notes tooling.

---

@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_01PqU92c7mMD1615k6QcSmBq

---

Generated by Claude Code

[Planeshifter]

Automation context: iteration log for reviewers

This PR was produced by a scheduled issue-resolution loop for stdlib-js/todo#2682. Distilled state, decision log, and verification record:

Task derivation

The referenced issue asks to add Git notes for two flawed commit messages from PR #8658, per the maintainer's comments issuecomment-3594907539 (symbol name anyOwnBy, not package name any-own-by) and issuecomment-3594913359 (@stdlib/objects/ → @stdlib/object/ typo). The repository's amend mechanism: docs/git-notes/<commit-hash>.txt files with type: amend-message front matter (per .github/workflows/git_note_amend_message.yml), applied by make apply-git-notes and consumed by the changelog tooling.

Key decisions

1. Target SHAs: the PR-branch commits (420eda3b, cfdd2da0) are not on develop — the PR was rebase-merged. The notes target the actual develop commits e3ff363a73067533e3479ba237d8e3d1cd76c45b and c04a8bc15913cb8d3130e255eea3078a82276e4e, verified via GitHub commit search (default-branch index) and by committer/merge-time match with PR feat: migrate utils/any-own-by to object/any-own-by #8658's merged_at.
2. Message content: copied verbatim from the maintainer's "should have been" blocks; no trailers added, since the original merged messages carry none.
3. Commit convention: one note per commit, subject docs: add Git note for commit <hash>, matching the bot workflow's own convention.

Verification performed

• git notes add -f -F <file> <hash> (the exact production command) applies both notes cleanly; round-trip via git notes show is byte-identical.
• Diff of original vs. note-amended messages shows only the intended corrections: 3 lines in e3ff363a (subject, body, BREAKING CHANGE line), 1 line in c04a8bc1. Zero remaining occurrences of the flaws in the amended texts.
• Front matter is byte-identical to workflow output; changelog parser extraction (_tools/changelog/parse-commits) simulated — yields exactly the corrected messages; no | / stray --- separator hazards; BREAKING CHANGE footers preserved, so version-bump recommendations are unchanged.
• Files: ASCII, LF-only, no trailing whitespace, single final newline; filenames pass the repo's filename-lint rules.
• Five independent adversarial review passes (correctness, test quality, conventions, security/robustness, issue scope) plus a reproduction-verification pass: zero blocker or major findings; scope audit found the diff does nothing beyond and misses nothing of the request.

Notes / open items for humans

• npm install fails in the automation sandbox (registry ETARGET on es-object-atoms@^1.1.2), so the authoritative make lint-* targets could not be run locally; the applicable checks were replicated manually and CI on this PR is authoritative.
• Candidate follow-up surfaced by review (out of scope here): docs/git-notes/ has no CI validation, and apply-git-notes swallows failures (|| echo), so a malformed note or bad hash would fail silently at standalone-publish time. A cheap lint guard (hash resolves to a commit, parseable front matter, known type, non-empty body) would close this.

---

Generated by Claude Code