docs(project-context): point Forgejo manual PR ops at the fj CLI #405

Merged
mph merged 1 commit from docs/forgejo-fj-cli-guidance into main 2026-07-11 10:48:36 +00:00
Owner

What

The Forgejo section emitted by iw project-context said only "Forgejo PR operations use direct HTTP (no CLI binary required)". That's accurate about how iw phase-pr/iw phase-merge work internally, but as agent guidance it left a gap: an agent doing a manual PR op got no pointer, whereas the GitHub section points at gh and the GitLab section points at glab.

Change

  • Point manual Forgejo PR ops at the fj CLI, parallel to the gh/glab sections.
  • Keep the accurate note that the automated iw phase-pr/phase-merge flow needs no forge CLI (direct HTTP) and still requires FORGEJO_API_TOKEN + tracker.baseUrl.
  • Include the --repo/-r slug caveat (<owner>/<name>, not a git remote name like origin) — the exact thing that tripped up first use when opening PR #404.

Scope note

ForgeType.cliTool deliberately stays None for Forgejo — iw-cli's own automation shells out to no forge CLI, so that's correct. This change is agent-facing guidance in project-context only.

Tests

Added a ProjectContextTest case asserting the Forgejo section keeps the direct-HTTP/token guidance and now surfaces fj pr create plus the slug caveat (TDD: written failing first). Full core.test green; -Werror compile clean.

🤖 Generated with Claude Code

## What The Forgejo section emitted by `iw project-context` said only *"Forgejo PR operations use direct HTTP (no CLI binary required)"*. That's accurate about how `iw phase-pr`/`iw phase-merge` work **internally**, but as agent guidance it left a gap: an agent doing a **manual** PR op got no pointer, whereas the GitHub section points at `gh` and the GitLab section points at `glab`. ## Change - Point manual Forgejo PR ops at the `fj` CLI, parallel to the gh/glab sections. - Keep the accurate note that the automated `iw phase-pr`/`phase-merge` flow needs no forge CLI (direct HTTP) and still requires `FORGEJO_API_TOKEN` + `tracker.baseUrl`. - Include the `--repo`/`-r` slug caveat (`<owner>/<name>`, **not** a git remote name like `origin`) — the exact thing that tripped up first use when opening PR #404. ## Scope note `ForgeType.cliTool` deliberately stays `None` for Forgejo — iw-cli's own automation shells out to no forge CLI, so that's correct. This change is agent-facing guidance in `project-context` only. ## Tests Added a `ProjectContextTest` case asserting the Forgejo section keeps the direct-HTTP/token guidance **and** now surfaces `fj pr create` plus the slug caveat (TDD: written failing first). Full `core.test` green; `-Werror` compile clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
docs(project-context): point Forgejo manual PR ops at the fj CLI
All checks were successful
CI / format (pull_request) Successful in 6s
CI / lint (pull_request) Successful in 5s
CI / contract (pull_request) Has been skipped
CI / compile (pull_request) Successful in 1m10s
CI / dashboard-build (pull_request) Successful in 52s
CI / test (pull_request) Successful in 9m29s
5e386dd646
The Forgejo section of `iw project-context` said only "direct HTTP (no
CLI binary required)" — accurate for the automated `iw phase-pr`/
`phase-merge` flow, but it left an agent doing a *manual* PR op with no
pointer, unlike the GitHub (`gh`) and GitLab (`glab`) sections.

Point manual PR ops at the `fj` CLI, keeping the accurate note that the
automated flow needs no forge CLI. Includes the `--repo`/`-r` slug caveat
(takes `<owner>/<name>`, not a remote name) that trips up first use.

`ForgeType.cliTool` stays None for Forgejo — iw-cli's own automation
genuinely shells out to no forge CLI; this is agent guidance only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mph merged commit 801b47d138 into main 2026-07-11 10:48:36 +00:00
Sign in to join this conversation.
No description provided.