Skip to content

Recovered review findings for repos with Issues disabled (superpowers, superpowers-marketplace, Instapaper-MCP, headroom) #64

Description

@twistedmelonman

Recovered from the ~/.claude/pending-issues/ fallback queue during twistedmelonman/dotfiles#231 triage.

These 12 findings belong to repos that have GitHub Issues disabled, so they cannot be filed where they belong. Verified 2026-08-24 (gh repo view --json hasIssuesEnabled, plus a create attempt that was refused):

repo issues fork? note
smartwatermelon/superpowers disabled no — detached content derived from obra/superpowers, but no fork link
smartwatermelon/superpowers-marketplace disabled no — detached same; lives as a submodule under claude-config
smartwatermelon/Instapaper-MCP disabled yes fork of hendronf/Instapaper-MCP
smartwatermelon/headroom disabled yes fork of headroomlabs-ai/headroom; also archived

Fork status corrected 2026-08-24. An earlier revision of this issue called the two superpowers repos forks and left the other two unmarked. That was backwards, and it matters for how actionable each section is.

gh api repos/<name> reports fork=false, parent=none for smartwatermelon/superpowers and smartwatermelon/superpowers-marketplace, while Instapaper-MCP and headroom report fork=true with live parents. The superpowers repos do still carry upstream ancestry — smartwatermelon/superpowers contains Jesse Vincent's commits 44c9b2d6 and 3dcbd5c4 (the v6.2.0 release) beneath the first local commit 18821ef9 — so these read as forks that were detached, not repos built from scratch. The repo was created 2026-07-31T18:17Z and the first local commit lands 59 minutes later.

Why this changes the triage: for a live fork there is a high bar to filing upstream, which is a reason to leave a finding alone. That reasoning does not apply to the superpowers pair — there is no upstream link to file against, and every finding below concerns local content (stale .gitattributes for deleted hook files, docs describing removed hooks, README vs marketplace.json drift, lingering obra/ links). Those 10 are ordinary local work; Issues being disabled is a settings choice, not a consequence of forking.

The two genuine forks are the opposite case. Instapaper-MCP's finding is a deleted README section — a local change to the fork, so no upstream question arises. headroom is both upstream-owned and archived, so its finding is effectively dead.

They are recorded here so the findings survive. If Issues is enabled on any of these repos later, split the relevant section out into that repo and tick it off here.

Caveat on the superpowers items: ~/Developer/superpowers is a checkout of upstream obra/superpowers at v5.0.5, not of smartwatermelon/superpowers. Attributing by that local checkout would have been wrong — hooks are still present in the upstream tree. These findings were verified against the live repo via gh api and the plugin cache at ~/.claude/plugins/cache/superpowers-marketplace/superpowers/6.3.0/. smartwatermelon/superpowers has no hooks/ directory.


smartwatermelon/superpowers (6 findings, 4 distinct defects)

Stale .gitattributes entries for deleted hook files

Merged from two findings covering the same defect.

  • .gitattributes retains stale patterns for deleted files (.gitattributes:3)

    Line 3 (hooks/session-start text eol=lf) and line 7 (*.cmd text eol=lf) now match no files in the repo — the files they governed were deleted by this diff. Git silently ignores .gitattributes rules for non-existent paths, so there is no functional breakage, but the entries are noise. They should be removed to avoid confusing future contributors who might infer these file types still exist.

Docs still describe deleted hook infrastructure as authoritative

Merged from three findings covering the same defect from different angles.

  • Documentation references deleted hook files as if they still exist (docs/porting-to-a-new-harness.md:787)

    docs/porting-to-a-new-harness.md (harness table at line ~787) and docs/windows/polyglot-hooks.md (line 3, 37–38, 53, 73) were not updated when the hook files were removed. Both documents still describe hooks/session-start, hooks/run-hook.cmd, hooks/hooks.json, and hooks/hooks-cursor.json as present and operative. The fork notice in CLAUDE.md acknowledges these are upstream docs kept for reference, so this is low risk in the fork context — but anyone treating these docs as authoritative for the current codebase will be misled. docs/windows/polyglot-hooks.md in particular says "Authoritative source: hooks/run-hook.cmd is the canonical implementation" for a file that no longer exists.

  • tests/hooks/test-session-start.sh deletion leaves documentation pointing at a non-existent test file (docs/porting-to-a-new-harness.md:578)

    docs/porting-to-a-new-harness.md:578 and docs/windows/polyglot-hooks.md:73 both refer readers to tests/hooks/test-session-start.sh as the place to run hook integration tests. That file was deleted by this diff. The tests/hooks/ directory itself may now be empty or gone. Not blocking for a personal fork, but the pointers are dead.

Codex-sync test assertions

  • tests/codex-plugin-sync assertions test upstream hook files this fork no longer ships (tests/codex-plugin-sync/test-sync-to-codex-plugin.sh:658)

    Lines 658-660 assert that a sync preview includes hooks/session-start, hooks/session-start-codex, and hooks/run-hook.cmd. These assertions pass because the test constructs a synthetic upstream fixture repo that creates those files — they don't reference the actual repo. Functionally fine. But the test scenario (syncing a fully-hooked upstream to Codex) diverges from what this fork actually does, so the test now documents a hypothetical that doesn't match reality. Low priority, but worth noting if the sync script is ever used in earnest.


smartwatermelon/superpowers-marketplace (4 findings, 3 distinct defects)

README vs marketplace.json disagree on private-journal-mcp feature list

Merged from two findings, one filed per side of the mismatch.

  • Description mismatch between marketplace.json and README for private-journal-mcp (.claude-plugin/marketplace.json:99 vs README.md:89)

    The two files disagree on what journal sections the plugin supports. marketplace.json says "reflections, observations, project notes, technical insights" while README.md says "feelings, project notes, technical insights, user context, world knowledge". These are the same diff introduction — both sides are new in this PR — so no pre-existing drift existed before. Pick one authoritative list, update the other to match, then keep them in sync going forward. As-is, users reading the README will form different expectations than those reading the JSON description.

  • README still references obra/superpowers after source URL changed to smartwatermelon/superpowers (README.md:32)

    The diff changed the superpowers plugin source URL from https://github.com/obra/superpowers.git to https://github.com/smartwatermelon/superpowers.git, but the README was not updated. Two stale links remain pointing to the old repo: line 32 (**Repository:** https://github.com/obra/superpowers) and line 111 (- **Core Plugin**: https://github.com/obra/superpowers). Installation still works correctly because the actual source URL in marketplace.json is right, but users clicking through the README to file issues, browse source, or check the changelog will land on the wrong repository.

  • Removing pinned commit ref trades reproducibility for HEAD-tracking (.claude-plugin/marketplace.json:10)

    The ref: "051c434d6bab69457bc9845f8d8fe4d0c1f925fe" was the only hard-pinned commit reference in this file. Removing it means superpowers will now install from HEAD of the default branch at install time, not a known-good commit. The version: "6.2.0" field remains unchanged, so the marketplace metadata and the actual installed code are now decoupled — a user installing "6.2.0" today gets a different artifact than a user installing "6.2.0" six months from now. This is consistent with how all other plugins in this file are defined (none of the others pin a commit either), so it's likely intentional alignment with that pattern rather than an oversight. The risk is that a breaking commit to the upstream superpowers repo will silently affect all installations with no version bump to signal the change.


smartwatermelon/Instapaper-MCP (1 finding)

  • Security Notes section removed from README (README.md:242-246 (removed section))

    The diff removes the "Security Notes" section which warned users never to commit .env, noted .gitignore protection, and clarified that credentials stay local. The .gitignore presumably still guards the file, but first-time users who don't read code (and only read the README for setup) no longer get the explicit reminder. Low risk — the section was brief and the behavior hasn't changed — but credential-leak guidance in a public-facing README is worth preserving. Consider adding a one-liner back near the Step 2 setup instructions (e.g., "Never commit your .env file — the .gitignore already excludes it.").


smartwatermelon/headroom (1 finding) — RESOLVED; fork deleted 2026-08-25

  • Reload tests leave sentinel objects cached in headroom.proxy.dict — fragile ordering assumption (tests/test_proxy_package_init.py:11-25)

    test_proxy_getattr_resolves_create_app_and_caches_it and test_proxy_getattr_resolves_run_server call importlib.reload(proxy), inject a fake headroom.proxy.server via monkeypatch, then invoke __getattr__ which caches sentinel objects into sys.modules["headroom.proxy"].__dict__ under the keys create_app and run_server. Monkeypatch correctly restores sys.modules["headroom.proxy.server"] on teardown, but does NOT restore the create_app/run_server entries it caused to be written into the headroom.proxy module dict. After these tests run, any code in the same process that accesses headroom.proxy.create_app (via the lazy getattr path — e.g., import headroom.proxy; headroom.proxy.create_app) would get a sentinel instead of the real function. Currently safe because every other test imports directly from headroom.proxy.server, bypassing the init cache entirely. But this is a latent trap: if any future test ever imports through the package init (the advertised public API), it will silently get garbage. Fix: add explicit cleanup after each reload test — module.__dict__.pop("create_app", None); module.__dict__.pop("run_server", None) — or use a dedicated autouse fixture that saves/restores sys.modules["headroom.proxy"].__dict__ keys for the duration of the test.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    tech-debtTechnical debt to address

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions