Dead code from the v1.0 single-entrypoint refactor: orphaned src/entrypoints/prepare.ts and three unused exports

Summary

The v1.0 consolidation onto a single run.ts entrypoint left behind an orphaned parallel copy of the prepare phase plus three unreferenced exports. The prepare.ts orphan is the one that matters: it is a plausible-looking duplicate of live logic, so a contributor can fix a bug in it and observe no effect.

CLAUDE.md documents the intended architecture:

Single entrypoint: src/entrypoints/run.ts orchestrates everything — prepare (auth, permissions, trigger check, branch/comment creation), install Claude Code CLI, execute Claude via base-action/ functions ... then cleanup

1. src/entrypoints/prepare.ts — orphaned duplicate of the prepare phase

103 lines, referenced by nothing:

$ grep -rn "entrypoints/prepare" --include="*.ts" --include="*.yml" src action.yml test base-action
(no output)

action.yml invokes only src/entrypoints/run.ts, src/entrypoints/cleanup-ssh-signing.ts, and src/entrypoints/post-buffered-inline-comments.ts. Nothing imports prepare.ts, and no test references it.

It imports and re-sequences the same modules run.ts uses — setupGitHubToken, checkWritePermissions, parseGitHubContext, detectMode, prepareTagMode, prepareAgentMode, checkContainsTrigger, collectActionInputsPresence — so it reads as a live alternative entrypoint. That is the hazard: it will drift from run.ts silently, and it is an inviting place to "fix" a prepare-phase bug with no runtime effect.

2. updateTrackingComment — no callers

src/github/operations/comments/update-with-branch.ts (57 lines) exports one function:

$ grep -rn "updateTrackingComment" --include="*.ts" src test | grep -v "update-with-branch.ts:"
(no output)

The branch-link-into-tracking-comment behaviour it implements is now handled by updateCommentLink in src/entrypoints/update-comment-link.ts via checkAndCommitOrDeleteBranch.

3. checkTriggerAction — no callers

src/github/validation/trigger.ts#L151-L155:

$ grep -rn "checkTriggerAction" --include="*.ts" src test | grep -v "trigger.ts:"
(no output)

run.ts calls checkContainsTrigger directly. The thin wrapper that additionally sets a contains_trigger output is unused, and no contains_trigger output is declared in action.yml.

4. Dead env exports the code already flags

src/create-prompt/index.ts#L984-L997 — the comment is in the source:

// NOTE: these env var exports are dead — nothing reads ALLOWED_TOOLS / DISALLOWED_TOOLS.
// The live path is modes/tag/index.ts which builds --allowedTools into claudeArgs directly.
// Kept only so the H1 report's pointed-to file stays in sync with the live fix.
const hasActionsReadPermission = false;

const allAllowedTools = buildAllowedToolsString(...);
const allDisallowedTools = buildDisallowedToolsString([], []);

core.exportVariable("ALLOWED_TOOLS", allAllowedTools);
core.exportVariable("DISALLOWED_TOOLS", allDisallowedTools);

Confirmed — nothing reads either variable:

$ grep -rn "ALLOWED_TOOLS\|DISALLOWED_TOOLS" --include="*.ts" --include="*.yml" src base-action action.yml \
    | grep -v "INPUT_ALLOWED\|INPUT_DISALLOWED"
src/modes/agent/parse-tools.ts:5:const ALLOWED_TOOLS_FLAGS = new Set(["allowedTools", "allowed-tools"]);
src/modes/agent/parse-tools.ts:64:    if (!ALLOWED_TOOLS_FLAGS.has(flag)) continue;
src/create-prompt/index.ts:34:const BASE_ALLOWED_TOOLS = ["Glob", "Grep", "LS", "Read"];
src/create-prompt/index.ts:42:  let baseTools = [...BASE_ALLOWED_TOOLS];
src/create-prompt/index.ts:984: // NOTE: these env var exports are dead ...
src/create-prompt/index.ts:996: core.exportVariable("ALLOWED_TOOLS", allAllowedTools);
src/create-prompt/index.ts:997: core.exportVariable("DISALLOWED_TOOLS", allDisallowedTools);

The only remaining references are the definitions themselves and an unrelated constant.

Note on item 4

The trailing comment — "Kept only so the H1 report's pointed-to file stays in sync with the live fix" — suggests this block was retained deliberately so a security report's referenced file still shows the corresponding change. If that reason still holds, this item should stay as-is; I've included it for completeness rather than proposing removal. Maintainers are better placed to judge.

Removing it would also require updating test/create-prompt.test.ts, which is currently the only consumer of buildAllowedToolsString and buildDisallowedToolsString.

Suggested fix

Items 1–3 are safe deletions. I'd propose them as one PR, or as three commits in one PR, whichever is easier to review — and leaving item 4 alone unless a maintainer confirms the H1 constraint has lapsed.

Before opening anything, I'd like confirmation on one point: is src/entrypoints/prepare.ts genuinely dead, or is it retained intentionally (for a documented manual invocation, or for a downstream consumer outside this repo)? I did not want to send a deletion PR against something being kept on purpose.

Environment

• Repository at d721746d683d812e669ce117cebe55a85fbd9c3e (main)