feat: add workflow_dispatch to OpenCode bot

[dceoy]

Summary

• add workflow_dispatch directly to .github/workflows/opencode-bot.yml
• mirror the complete workflow_call input contract for direct dispatch
• preserve the existing workflow_call, issue-comment, and review-comment paths
• document direct dispatch through the Actions UI or authorized workflow-dispatch API clients/integrations

Design

opencode-bot.yml remains the single execution surface. workflow_dispatch.inputs matches workflow_call.inputs, while the existing job guard requires a non-empty prompt for non-comment runs.

Direct workflow_dispatch is intentionally repository-scoped: dispatching this workflow runs against the repository that contains it. Consumer repositories continue to use opencode-bot.yml as a reusable workflow from a caller workflow in the consumer repository, preserving that repository's GitHub context and workspace. Cross-repository target selection is outside this PR because it would require a separate repository/ref and authentication contract.

CKV_GHA_7 is suppressed only for this workflow because parameterized manual dispatch is the intended trusted-operator interface.

Validation

• diff is limited to opencode-bot.yml, README.md, and docs/reusable-workflows.md
• existing comment and reusable-workflow triggers remain intact
• repository CI covers workflow linting, security scanning, Markdown linting, and tests

[opencode-agent]

One documentation wording issue found; the workflow and its security boundaries look correct.

[opencode-agent]

Review complete. I submitted one inline suggestion on docs/reusable-workflows.md regarding a misleading permission description, and verified the workflow mechanics and security boundaries are sound. The rest of the PR looks good.

opencode session  |  github run

[claude]

Review summary — PR #118 (add opencode-dispatch.yml)

Ran pr-review-toolkit:review-pr (code, comments, tests, errors) and Claude Code's security-review in parallel against gh pr diff 118, cross-checked all candidate findings against the current file contents and the two sibling reusable workflows (opencode-bot.yml, opencode-review.yml), and independently verified each with markdownlint-cli2 / manual reasoning about GitHub Actions semantics before posting.

Workflow YAML (opencode-dispatch.yml): structurally sound and closely modeled on the existing reusable workflows. The if: github.event_name == 'workflow_dispatch' job gate, uses: $/. self-reference, persist-credentials/GH_TOKEN fallback pattern, and input/secret wiring all match established repo conventions and check out correctly. I also evaluated (and, after adversarial filtering, rejected as not actionable) a theory that the new contents: write permission combined with the always-set GITHUB_TOKEN env var could let a prompt-injected agent escalate a write — this turns out to be an existing pattern already present in the sibling workflows and an intentional, documented trust decision tied to workflow_dispatch's actor restriction, not a defect introduced by this PR.

Documentation (docs/reusable-workflows.md): left 3 inline comments — a table formatting bug and two accuracy/clarity issues:

• Line 117: the prompt row breaks table column alignment (confirmed via markdownlint-cli2: the only MD060/table-column-style violation in the file).
• Line 133: the rewritten GH_TOKEN paragraph conflates the use-github-token opt-in with the fixed contents permission ceiling (which is actually set unconditionally by each workflow's permissions: block), and drops previously-present, still-relevant 403 troubleshooting guidance for the bot/review workflows.
• Line 137: "requests the same permissions except contents: write" is ambiguous wording that reads as excluding that permission rather than substituting it for contents: read.

No test-coverage gaps, silent-failure risks, or high-confidence security vulnerabilities were found beyond the above documentation issues — CI's glob-based lint/scan jobs already cover the new workflow file equivalently to its siblings.

[dceoy]

Reviewed the latest head. The workflow_call / workflow_dispatch input parity is structurally valid on GitHub.com, and actionlint/yamllint/zizmor all pass. Two CI blockers remain: the intentional workflow_dispatch inputs trip Checkov CKV_GHA_7 and need an explicit, documented exception; the README workflow table has one MD060 alignment failure. No additional correctness issues found in the dispatch wiring.

[dceoy]

Two issues remain in the direct-dispatch design/documentation. The input contract itself is valid (12 inputs is below GitHub.com's current limit, and number is supported).

[dceoy]

Reviewed the latest head (d1121b7). No blocking findings.

• workflow_dispatch.inputs now matches the full workflow_call.inputs contract: names, types, required flags, and defaults are aligned.
• The 12 dispatch inputs are valid on GitHub.com (current limit: 25); number is supported for timeout-minutes.
• The existing non-comment job guard correctly prevents an empty prompt from executing even though prompt remains schema-optional to preserve parity with workflow_call.
• The direct-dispatch repository scope is now explicitly documented, avoiding the earlier implication that it targets arbitrary consumer repositories.
• CKV_GHA_7 is suppressed narrowly at the intended manual-dispatch resource rather than globally.
• Latest CI is green across Actions lint/security scanning, Markdown lint/formatting, Bats tests, CodeQL, and shell lint.

The workflow rename to OpenCode bot is UI-only and does not affect reusable callers, which reference the workflow by path. Ready from a code-review standpoint.