Evaluate the structuredpath fork for selective upstreaming

[lukaskubanek]

@steipete Hi Peter, I just noticed you’re picking up work on the InterposeKit library again. That’s great news!

I just wanted to let you know that in the meantime, while you were away, I iterated on your codebase and made some improvements, especially around usability. The code currently lives at https://github.com/structuredpath/InterposeKit on main and I haven’t yet managed to cut a release. I’ve also detached it from being a fork, as the changes were rather significant and I wasn’t sure about the future of this upstream repo. I thought I’d point you to it in case any of the ideas are useful. Feel free to use them. 🙂

(Opening an issue for this, as the repo currently doesn’t support discussions.)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 11, 2026, 5:17 AM ET / 09:17 UTC.

Summary
The linked fork contains a substantial redesign with concrete API, lifecycle, concurrency, packaging, and test changes that current main does not subsume. This fresh informational issue remains useful as a maintainer decision point and satisfies no conservative close reason.

Reproducibility: not applicable. This issue shares an external implementation and does not report a failing current-main behavior.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Maintainer product and compatibility judgment is required to select and sequence the fork changes before any focused implementation can be queued.

Review details

Best possible solution:

Have the upstream and fork owners identify the highest-value changes, then propose them as focused issues or pull requests with explicit API compatibility, migration, lifecycle, and concurrency tests.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this issue shares an external implementation and does not report a failing current-main behavior.

Is this the best way to solve the issue?

No, adopting the fork wholesale is not yet established as the best solution; selectively upstreaming independently testable improvements is the narrower and safer path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The fork removes deprecated APIs and substantially restructures public hook APIs, so wholesale adoption could break existing clients and needs explicit compatibility and migration decisions.
• The fork also changes lifecycle, object-hook registry, concurrency, platform, and packaging behavior; those independent changes should not be evaluated as a single implicit merge request.

Codex review notes: model internal, reasoning high; reviewed against a29733d40a88.

Label changes

Label changes:

• add P3: This is a fresh, non-urgent upstreaming and usability discussion with no reported regression or user outage.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a fresh, non-urgent upstreaming and usability discussion with no reported regression or user outage.

Evidence reviewed

What I checked:

• External implementation scope: The fork documents broad changes over upstream, including a fluent hook builder, explicit hook lifecycle control, centralized object-hook coordination, structured errors, Swift concurrency support, and SwiftPM-only packaging. (51e771584551)
• Current upstream surface: Current main retains the original Interpose/ObjectHook/ClassHook-oriented layout rather than the fork's Hooks/HookBuilder/HookScope architecture, so the central proposal has not already been implemented wholesale. (Sources/InterposeKit/ObjectHook.swift:7, a29733d40a88)
• Original feature history: Object-level interposition was introduced in commit 9e387e1 and subsequently refactored and linted in commits 4bcf98e and 7a9367e, all by Peter Steinberger. (Sources/InterposeKit/ObjectHook.swift:1, 9e387e1e8936)
• Recent upstream maintenance: Current main includes fresh object-hook lifetime and trampoline fixes merged on June 11, 2026, showing active upstream work but not adoption of the fork's broader usability design. (Sources/InterposeKit/ObjectHook.swift:1, 516643382662)
• Canonical search: A repository-wide GitHub issue search for the linked fork found only this issue, with no separate canonical issue or pull request owning the proposed evaluation.
• Repository policy: The applicable AGENTS.md requires conservative, evidence-backed, proposal-only review handling; no target VISION.md was present.

Likely related people:

• steipete: Peter Steinberger introduced the central object-hook behavior, performed its early refactors, and authored current main's June 2026 lifetime and trampoline fixes. (role: original feature owner and recent area contributor; confidence: high; commits: 9e387e1e8936, 4bcf98e02596, 516643382662; files: Sources/InterposeKit/ObjectHook.swift, Sources/InterposeKit/ClassHook.swift, Sources/InterposeKit/InterposeSubclass.swift)
• lukaskubanek: Lukas Kubanek authored the linked redesign and its documentation, making them the best source for intent and for decomposing the fork into focused upstream proposals. (role: external implementation owner; confidence: high; commits: 51e771584551, 1f3fe5bfef28, 16f47af14c7c; files: README.md, Sources/InterposeKit/Hooks/Hook.swift, Sources/InterposeKit/Hooks/HookBuilder.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Thanks for sharing this, Lukas. I audited https://github.com/structuredpath/InterposeKit at 51e7715 against upstream master at 2492331.

Maintainer decision: do not upstream the fork wholesale. It is 187 commits and 113 changed files past the common base, with intentional public and packaging breaks: a replacement hook API/lifecycle, higher Swift and OS minimums, SwiftPM-only distribution, removal of batch builders and delayed hooks, and new class-method behavior. It also still tracks unresolved correctness work around arbitrary hook-chain reversion, super lookup, and registry lifetime:

• Handle case with two class hooks and reverting first before second structuredpath/InterposeKit#12
• Wrong lookup behavior in super trampoline when subclasses override below injection structuredpath/InterposeKit#21
• Hunt down memory leak of WeakReference in ObjectHookRegistry structuredpath/InterposeKit#27

I ran the fork's 34 tests in debug and release on macOS 26.5 with Xcode 26.6 / Swift 6.3.3; they pass, with two Swift concurrency warnings in the KVO tests. Useful independent fixes represented in the fork have already landed upstream through focused work at #37 and #42. The weak-lifetime API candidate is isolated and decision-ready at #36.

Any remaining idea should arrive as its own focused issue or pull request with a compatibility contract and regression proof; the fork itself is not a merge candidate. Closing this informational pointer as reviewed. Thank you for preserving and offering the work.