jbr870/forgejo-mcp-server
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Add project board tools (projects, columns, cards) #13

New issue
Open
opened 2026-04-20 13:24:39 +00:00 by jbr870 · 1 comment
jbr870 commented 2026-04-20 13:24:39 +00:00
Owner
Copy link

Problem

The MCP server lets agents manage issues, comments, labels, and wiki pages on a Forgejo repo, but it has no coverage for Forgejo's project boards. As a result, an agent can create and label an issue but cannot place it on a board, move it across columns as work progresses, or set up the board itself. Anyone using boards to coordinate work has to drop out of chat and into the Forgejo web UI to do anything board-related, which breaks the "fully agentic repo workflow" story.

It is now feasible to close this gap: upstream Forgejo recently landed a complete project-board REST API (forgejo/forgejo PR #9384) covering CRUD for projects, columns, and cards including reordering. Source: Forgejo issue #13.

Users:

  • Primary: MCP agents coordinating work on Forgejo repositories on behalf of end users — bootstrapping boards on fresh repos, placing issues onto boards, moving cards as work progresses.
  • Secondary: End users relying on agents to drive their full board-based workflow from chat without context-switching into the Forgejo web UI.

Current state: All board operations (creating projects, adding/renaming/recoloring columns, placing issues on boards, moving cards) happen exclusively in the Forgejo web UI. The agent has no way to observe or modify board state.

Proposed Solution

Add MCP tools that wrap the Forgejo project-board REST API end-to-end. The tools live in a new src/tools/projects.py module alongside the existing tool families and follow the same plumbing already proven by issue-10-label-management: ForgejoClient for HTTP, _resolve_token_and_instance for per-user auth, _validate_owner_repo for input hardening, and the standard {"error": "..."} shape for ForgejoConnectionError / ForgejoAPIError.

The surface covers three resources:

  • Projects (CRUD) — both repo-scoped (/api/v1/repos/{owner}/{repo}/projects) and org-scoped (/api/v1/orgs/{org}/projects). Repo and org scopes are exposed as separate, explicitly-named tools (list_repo_projects vs list_org_projects, create_repo_project vs create_org_project, etc.) so each tool's parameters are unambiguous. This continues the explicit-naming precedent from issue-11.
  • Columns (CRUD + set-default) — column lifecycle on a given project (title, color, default-column flag).
  • Cards (issue ↔ project assignment) — add_issue_to_project (lands in the project's default column), remove_issue_from_project, move_card (column + position; this is the only "assign to column" primitive in the underlying API), list_column_cards. The two primitives are kept separate; their tool descriptions explicitly document the two-step "add then move" pattern so agents can sequence them without us hiding a non-atomic composite.

Scope: Full — all three resources, both scopes for projects, no functionality deferred to a follow-up. Each individual tool is a thin wrapper over a single Forgejo endpoint, which matches the issue-10 pattern that landed cleanly in one feature.

User Stories

  • As an MCP agent, I want to list projects on a repo or org so that I can discover existing boards before creating new ones.
  • As an MCP agent, I want to fetch a single project's details so that I can show the user the current board state.
  • As an MCP agent, I want to create, update, and delete projects on either a repo or an org so that I can bootstrap and maintain board structures end-to-end.
  • As an MCP agent, I want to list, create, update, delete, and set the default column on a project so that I can shape a board's workflow stages without leaving chat.
  • As an MCP agent, I want to add an existing issue to a project as a card so that I can place tracked work onto the right board.
  • As an MCP agent, I want to move a card to a specific column and position so that I can reflect status changes (e.g. "in progress" → "review") as work proceeds.
  • As an MCP agent, I want to list the cards in a column and remove a card from a project so that I can audit and clean up board state.
  • As an end user, I want my agent to drive my full board-based workflow from chat so that I don't have to context-switch into the Forgejo web UI to manage boards.

Acceptance Criteria

  • Given a valid repo and authenticated user, when the agent calls list_repo_projects, then the response contains every project on the repo with at least id, title, description, and state.
  • Given a valid org and authenticated user, when the agent calls list_org_projects, then the response contains every project on the org with the same fields.
  • Given an existing project id, when the agent calls the project-detail tool, then the response contains the project including its columns when applicable.
  • Given a valid repo (or org) and a project payload (title, description, board type), when the agent calls the corresponding create_*_project tool, then the project is created on the correct scope and the response contains the created project with its assigned id.
  • Given an existing project id and partial field updates, when the agent calls the update tool, then only the supplied fields are changed and the response reflects the updated project.
  • Given an existing project id, when the agent calls the delete tool, then the project is removed and a subsequent list does not include it.
  • Given an existing project, when the agent calls list_project_columns, then the response contains every column with id, title, color, and a flag indicating which column is the default.
  • Given an existing project, when the agent calls create_column / update_column / delete_column, then the column is created / partially updated / removed and subsequent list calls reflect the change.
  • Given an existing column on a project, when the agent calls set_default_column, then that column becomes the project's default and a subsequent project / column listing reflects the new default.
  • Given an existing project and an existing issue, when the agent calls add_issue_to_project, then a card representing that issue appears on the board in the project's default column.
  • Given a card already on a project, when the agent calls move_card with a target column_id and position, then the card moves to that column at that position and a subsequent list_column_cards reflects the move.
  • Given a card already on a project, when the agent calls remove_issue_from_project, then the card is removed from the board and a subsequent list_column_cards does not include it.
  • Given an existing column, when the agent calls list_column_cards, then the response contains every card in that column with at least the linked issue's index/id and the card's position.
  • Given an invalid owner/repo or org name, when any project / column / card tool is called, then the tool returns an owner/repo (or org) validation error without calling the Forgejo API.
  • Given no token is configured and no per-user token is resolvable, when any tool is called, then the tool returns the standard "No token configured" error message used by existing tools.
  • Given the Forgejo API returns an error (e.g. 404 for missing project / column / card id, 422 for invalid payload), when any tool is called, then the tool returns the standard {"error": "Forgejo API error <code>: <detail>"} shape.
  • Given the Forgejo instance is unreachable, when any tool is called, then the tool returns the standard {"error": "Cannot connect to Forgejo: ..."} shape.
  • Given the Forgejo instance is older than the documented minimum version (no project-board API), when any tool is called, then the underlying 404 / 501 from the instance surfaces as a standard ForgejoAPIError (no custom version-probe layer).
  • Given the existing issue / comment / label / wiki tools, when the new tools are registered, then the existing tools continue to work unchanged.

Out of Scope

  • Active Forgejo-version probing. Will document the minimum Forgejo version in the README and rely on natural API errors from older instances. No probe-and-cache layer in this feature.
  • Composite "add issue to column" helper. Keeping add_issue_to_project and move_card as distinct primitives mirrors the underlying API; tool descriptions document the two-step pattern. A composite would hide a non-atomic two-step.
  • Label-to-column binding, auto-move-on-close, column hooks — none of these exist in upstream Forgejo (tracked in forgejo/forgejo issues #4462, #773, #6733).
  • Bulk board import/export (e.g. import a JSON board template).
  • Cross-repo / cross-org board mirroring helpers.
  • Board analytics (card aging, column throughput, etc.).
  • UI / web routes for board management — this is MCP-tool-only, like issue-10-label-management.

Dependencies

  • Existing ForgejoClient in src/forgejo_client.py — will be extended with project / column / card methods.
  • Existing _resolve_token_and_instance and _validate_owner_repo helpers in src/tools/_resolve.py.
  • New src/tools/projects.py module with a register_project_tools entry point, wired into src/tools/__init__.py:register_tools alongside the existing four register_*_tools calls.
  • Forgejo project-board REST API (forgejo/forgejo PR #9384). Documented minimum Forgejo version to be pinned in the README during implementation.

Notes

  • Key decisions:
    • Full surface in one feature. All three resources (projects, columns, cards) shipped together — each tool is a thin wrapper over a single Forgejo endpoint, so the marginal cost of additional tools is small. Mirrors the issue-10-label-management precedent.
    • Separate tools for repo vs org project scope. list_repo_projects / list_org_projects, etc. — each tool's parameters are unambiguous, continuing the explicit-naming precedent from issue-11-standardize-param-names.
    • Document min Forgejo version, fail naturally. No active version probe; older instances surface natural API errors.
    • No composite card-placement helper. add_issue_to_project + move_card stay as primitives; tool descriptions document the two-step pattern.
  • Open questions: None at PREQ stage. Implementation-level details — exact endpoint paths for get_project / update_project / delete_project (whether they're scope-prefixed or use the global project id), the precise move_card payload shape, default-column toggling semantics, and which Forgejo version pins as the minimum — are deferred to /technical-plan.

Status (2026-04-24): Paused. See comment below for pause reason, SREQ summary, and resume trigger. Technical plan lives at devwork/backlog/issue-13-project-board-tools/SREQ.md on branch feature/issue-13-project-board-tools.

## Problem The MCP server lets agents manage issues, comments, labels, and wiki pages on a Forgejo repo, but it has no coverage for Forgejo's project boards. As a result, an agent can create and label an issue but cannot place it on a board, move it across columns as work progresses, or set up the board itself. Anyone using boards to coordinate work has to drop out of chat and into the Forgejo web UI to do anything board-related, which breaks the "fully agentic repo workflow" story. It is now feasible to close this gap: upstream Forgejo recently landed a complete project-board REST API (forgejo/forgejo PR #9384) covering CRUD for projects, columns, and cards including reordering. Source: Forgejo issue #13. **Users:** - **Primary:** MCP agents coordinating work on Forgejo repositories on behalf of end users — bootstrapping boards on fresh repos, placing issues onto boards, moving cards as work progresses. - **Secondary:** End users relying on agents to drive their full board-based workflow from chat without context-switching into the Forgejo web UI. **Current state:** All board operations (creating projects, adding/renaming/recoloring columns, placing issues on boards, moving cards) happen exclusively in the Forgejo web UI. The agent has no way to observe or modify board state. ## Proposed Solution Add MCP tools that wrap the Forgejo project-board REST API end-to-end. The tools live in a new `src/tools/projects.py` module alongside the existing tool families and follow the same plumbing already proven by `issue-10-label-management`: `ForgejoClient` for HTTP, `_resolve_token_and_instance` for per-user auth, `_validate_owner_repo` for input hardening, and the standard `{"error": "..."}` shape for `ForgejoConnectionError` / `ForgejoAPIError`. The surface covers three resources: - **Projects** (CRUD) — both repo-scoped (`/api/v1/repos/{owner}/{repo}/projects`) and org-scoped (`/api/v1/orgs/{org}/projects`). Repo and org scopes are exposed as **separate, explicitly-named tools** (`list_repo_projects` vs `list_org_projects`, `create_repo_project` vs `create_org_project`, etc.) so each tool's parameters are unambiguous. This continues the explicit-naming precedent from `issue-11`. - **Columns** (CRUD + set-default) — column lifecycle on a given project (title, color, default-column flag). - **Cards** (issue ↔ project assignment) — `add_issue_to_project` (lands in the project's default column), `remove_issue_from_project`, `move_card` (column + position; this is the only "assign to column" primitive in the underlying API), `list_column_cards`. The two primitives are kept separate; their tool descriptions explicitly document the two-step "add then move" pattern so agents can sequence them without us hiding a non-atomic composite. **Scope:** Full — all three resources, both scopes for projects, no functionality deferred to a follow-up. Each individual tool is a thin wrapper over a single Forgejo endpoint, which matches the `issue-10` pattern that landed cleanly in one feature. ## User Stories - As an MCP agent, I want to list projects on a repo or org so that I can discover existing boards before creating new ones. - As an MCP agent, I want to fetch a single project's details so that I can show the user the current board state. - As an MCP agent, I want to create, update, and delete projects on either a repo or an org so that I can bootstrap and maintain board structures end-to-end. - As an MCP agent, I want to list, create, update, delete, and set the default column on a project so that I can shape a board's workflow stages without leaving chat. - As an MCP agent, I want to add an existing issue to a project as a card so that I can place tracked work onto the right board. - As an MCP agent, I want to move a card to a specific column and position so that I can reflect status changes (e.g. "in progress" → "review") as work proceeds. - As an MCP agent, I want to list the cards in a column and remove a card from a project so that I can audit and clean up board state. - As an end user, I want my agent to drive my full board-based workflow from chat so that I don't have to context-switch into the Forgejo web UI to manage boards. ## Acceptance Criteria - [ ] Given a valid repo and authenticated user, when the agent calls `list_repo_projects`, then the response contains every project on the repo with at least `id`, `title`, `description`, and `state`. - [ ] Given a valid org and authenticated user, when the agent calls `list_org_projects`, then the response contains every project on the org with the same fields. - [ ] Given an existing project id, when the agent calls the project-detail tool, then the response contains the project including its columns when applicable. - [ ] Given a valid repo (or org) and a project payload (title, description, board type), when the agent calls the corresponding `create_*_project` tool, then the project is created on the correct scope and the response contains the created project with its assigned id. - [ ] Given an existing project id and partial field updates, when the agent calls the update tool, then only the supplied fields are changed and the response reflects the updated project. - [ ] Given an existing project id, when the agent calls the delete tool, then the project is removed and a subsequent list does not include it. - [ ] Given an existing project, when the agent calls `list_project_columns`, then the response contains every column with `id`, `title`, `color`, and a flag indicating which column is the default. - [ ] Given an existing project, when the agent calls `create_column` / `update_column` / `delete_column`, then the column is created / partially updated / removed and subsequent list calls reflect the change. - [ ] Given an existing column on a project, when the agent calls `set_default_column`, then that column becomes the project's default and a subsequent project / column listing reflects the new default. - [ ] Given an existing project and an existing issue, when the agent calls `add_issue_to_project`, then a card representing that issue appears on the board in the project's default column. - [ ] Given a card already on a project, when the agent calls `move_card` with a target `column_id` and `position`, then the card moves to that column at that position and a subsequent `list_column_cards` reflects the move. - [ ] Given a card already on a project, when the agent calls `remove_issue_from_project`, then the card is removed from the board and a subsequent `list_column_cards` does not include it. - [ ] Given an existing column, when the agent calls `list_column_cards`, then the response contains every card in that column with at least the linked issue's index/id and the card's position. - [ ] Given an invalid owner/repo or org name, when any project / column / card tool is called, then the tool returns an owner/repo (or org) validation error without calling the Forgejo API. - [ ] Given no token is configured and no per-user token is resolvable, when any tool is called, then the tool returns the standard "No token configured" error message used by existing tools. - [ ] Given the Forgejo API returns an error (e.g. 404 for missing project / column / card id, 422 for invalid payload), when any tool is called, then the tool returns the standard `{"error": "Forgejo API error <code>: <detail>"}` shape. - [ ] Given the Forgejo instance is unreachable, when any tool is called, then the tool returns the standard `{"error": "Cannot connect to Forgejo: ..."}` shape. - [ ] Given the Forgejo instance is older than the documented minimum version (no project-board API), when any tool is called, then the underlying 404 / 501 from the instance surfaces as a standard `ForgejoAPIError` (no custom version-probe layer). - [ ] Given the existing issue / comment / label / wiki tools, when the new tools are registered, then the existing tools continue to work unchanged. ## Out of Scope - **Active Forgejo-version probing.** Will document the minimum Forgejo version in the README and rely on natural API errors from older instances. No probe-and-cache layer in this feature. - **Composite "add issue to column" helper.** Keeping `add_issue_to_project` and `move_card` as distinct primitives mirrors the underlying API; tool descriptions document the two-step pattern. A composite would hide a non-atomic two-step. - **Label-to-column binding, auto-move-on-close, column hooks** — none of these exist in upstream Forgejo (tracked in forgejo/forgejo issues #4462, #773, #6733). - **Bulk board import/export** (e.g. import a JSON board template). - **Cross-repo / cross-org board mirroring** helpers. - **Board analytics** (card aging, column throughput, etc.). - **UI / web routes** for board management — this is MCP-tool-only, like `issue-10-label-management`. ## Dependencies - Existing `ForgejoClient` in `src/forgejo_client.py` — will be extended with project / column / card methods. - Existing `_resolve_token_and_instance` and `_validate_owner_repo` helpers in `src/tools/_resolve.py`. - New `src/tools/projects.py` module with a `register_project_tools` entry point, wired into `src/tools/__init__.py:register_tools` alongside the existing four `register_*_tools` calls. - Forgejo project-board REST API (forgejo/forgejo PR #9384). Documented minimum Forgejo version to be pinned in the README during implementation. ## Notes - **Key decisions:** - **Full surface in one feature.** All three resources (projects, columns, cards) shipped together — each tool is a thin wrapper over a single Forgejo endpoint, so the marginal cost of additional tools is small. Mirrors the `issue-10-label-management` precedent. - **Separate tools for repo vs org project scope.** `list_repo_projects` / `list_org_projects`, etc. — each tool's parameters are unambiguous, continuing the explicit-naming precedent from `issue-11-standardize-param-names`. - **Document min Forgejo version, fail naturally.** No active version probe; older instances surface natural API errors. - **No composite card-placement helper.** `add_issue_to_project` + `move_card` stay as primitives; tool descriptions document the two-step pattern. - **Open questions:** None at PREQ stage. Implementation-level details — exact endpoint paths for `get_project` / `update_project` / `delete_project` (whether they're scope-prefixed or use the global project id), the precise `move_card` payload shape, default-column toggling semantics, and which Forgejo version pins as the minimum — are deferred to `/technical-plan`. --- > **Status (2026-04-24): Paused.** See comment below for pause reason, SREQ summary, and resume trigger. Technical plan lives at `devwork/backlog/issue-13-project-board-tools/SREQ.md` on branch `feature/issue-13-project-board-tools`.
jbr870 commented 2026-04-24 12:54:43 +00:00
Author
Owner
Copy link

Status: paused (2026-04-24)

Pause reason — upstream API not merged

The PREQ's premise (referenced in the issue description) is that Forgejo has a complete project-board REST API ready to wrap. Research during /technical-plan shows this is not yet the case:

  • PR #9384 ("feat: Add complete project board API implementation") — closed 2026-02-27, not merged.
  • PR #11761 ("WIP: feat/project-api-openapi", the successor) — closed 2026-03-23, not merged. Author cited the Forgejo no-AI-tooling policy in both cases.
  • PR #11334 ("fix(models): deduplicate project sorting values and add unique constraints") — merged, targets Forgejo v15 — but it is data-model + migration only; it ships no HTTP handlers.

Direct inspection of https://code.forgejo.org/swagger.v1.json confirms: no paths under /projects, /columns, or /cards exist in the shipping OpenAPI spec as of 2026-04-24.

Building the MCP tools against the closed PRs' draft shape would ship 13 agent-facing tools that return 404 on every real Forgejo instance. Unit tests (mocked) would pass; every live invocation would fail. Not a useful shipping state.

SREQ — summary

Full technical plan lives on branch feature/issue-13-project-board-tools at devwork/backlog/issue-13-project-board-tools/SREQ.md. Key decisions captured so the work can resume without starting from scratch:

  • Module layout. Single new src/tools/projects.py with register_project_tools, organised into three comment-separated sections (projects / columns / cards). Mirrors the issue-10-label-management precedent.
  • Target endpoint surface (from PR #11761 draft — re-verify on resume):
    • Projects: /api/v1/repos/{owner}/{repo}/projects[/:id] and /api/v1/orgs/{org}/projects[/:id].
    • Columns: /api/v1/projects/{project_id}/columns[/:column_id] — globally keyed on project id.
    • Cards: /api/v1/columns/{column_id}/cards, POST /api/v1/cards/{card_id}/move with {"column_id": <int>, "position": <int>}, DELETE /api/v1/cards/{card_id} — globally keyed on column / card id.
  • add_issue_to_project is a two-step: resolve project default column, then POST /columns/{column_id}/cards. Tool returns the resolved column_id for auditability (TOCTOU is possible if default column changes between calls).
  • remove_issue_from_project is a three-step composite: list columns → list cards per column → DELETE /cards/{card_id}. Non-atomic, O(columns × cards). Tool returns deleted_card_id for idempotent retry on partial failure. Alternative primitive (remove_card_by_id) explicitly rejected — PREQ names the tool by issue, not card.
  • Repo vs org projects stay as separate explicitly-named tools (list_repo_projects / list_org_projects, etc.), per issue-11 precedent.
  • Shared input validation. New _validate_org + _validate_positive_int helpers in src/tools/_resolve.py, both built on the same character-test helper as _validate_owner_repo (no re-implementation — the /simplify drift noted in CLAUDE.md was the reason for unifying).
  • Trust boundary. Column/card tools accept integer IDs only; Forgejo enforces per-token authorization. IDOR surface is acknowledged and documented; no per-call ownership probe at the MCP layer.
  • Expert review. Tier 2 panel (Backend, Security, Solution Architect). All three independently flagged the upstream-API-not-merged issue as the blocker that triggers this pause.

Total tool surface on resume: 13 tools across three resources. 21 acceptance criteria (19 from PREQ + 2 from expert review: integer-ID bounds, shared-validator parity).

Resume trigger

Unpause when a Forgejo release ships REST handlers under the paths above. On resume:

  1. Re-verify the merged endpoint shapes against the SREQ's Key Decisions table — paths and payloads may differ from the PR #11761 draft.
  2. Pin the minimum Forgejo version in README.
  3. Lift the SREQ's "Status: paused" note and move the feature folder from devwork/backlog/ to devwork/in-development/.
  4. Run /develop.

Tracked upstream:

## Status: paused (2026-04-24) ## Pause reason — upstream API not merged The PREQ's premise (referenced in the issue description) is that Forgejo has a complete project-board REST API ready to wrap. Research during `/technical-plan` shows this is not yet the case: - **PR #9384** ("feat: Add complete project board API implementation") — **closed 2026-02-27**, not merged. - **PR #11761** ("WIP: feat/project-api-openapi", the successor) — **closed 2026-03-23**, not merged. Author cited the Forgejo no-AI-tooling policy in both cases. - **PR #11334** ("fix(models): deduplicate project sorting values and add unique constraints") — **merged, targets Forgejo v15** — but it is data-model + migration only; it ships no HTTP handlers. Direct inspection of `https://code.forgejo.org/swagger.v1.json` confirms: no paths under `/projects`, `/columns`, or `/cards` exist in the shipping OpenAPI spec as of 2026-04-24. Building the MCP tools against the closed PRs' draft shape would ship 13 agent-facing tools that return `404` on every real Forgejo instance. Unit tests (mocked) would pass; every live invocation would fail. Not a useful shipping state. ## SREQ — summary Full technical plan lives on branch `feature/issue-13-project-board-tools` at `devwork/backlog/issue-13-project-board-tools/SREQ.md`. Key decisions captured so the work can resume without starting from scratch: - **Module layout.** Single new `src/tools/projects.py` with `register_project_tools`, organised into three comment-separated sections (projects / columns / cards). Mirrors the `issue-10-label-management` precedent. - **Target endpoint surface** (from PR #11761 draft — re-verify on resume): - Projects: `/api/v1/repos/{owner}/{repo}/projects[/:id]` and `/api/v1/orgs/{org}/projects[/:id]`. - Columns: `/api/v1/projects/{project_id}/columns[/:column_id]` — globally keyed on project id. - Cards: `/api/v1/columns/{column_id}/cards`, `POST /api/v1/cards/{card_id}/move` with `{"column_id": <int>, "position": <int>}`, `DELETE /api/v1/cards/{card_id}` — globally keyed on column / card id. - **`add_issue_to_project`** is a two-step: resolve project default column, then `POST /columns/{column_id}/cards`. Tool returns the resolved `column_id` for auditability (TOCTOU is possible if default column changes between calls). - **`remove_issue_from_project`** is a three-step composite: list columns → list cards per column → `DELETE /cards/{card_id}`. Non-atomic, O(columns × cards). Tool returns `deleted_card_id` for idempotent retry on partial failure. Alternative primitive (`remove_card_by_id`) explicitly rejected — PREQ names the tool by issue, not card. - **Repo vs org projects** stay as separate explicitly-named tools (`list_repo_projects` / `list_org_projects`, etc.), per `issue-11` precedent. - **Shared input validation.** New `_validate_org` + `_validate_positive_int` helpers in `src/tools/_resolve.py`, both built on the same character-test helper as `_validate_owner_repo` (no re-implementation — the `/simplify` drift noted in CLAUDE.md was the reason for unifying). - **Trust boundary.** Column/card tools accept integer IDs only; Forgejo enforces per-token authorization. IDOR surface is acknowledged and documented; no per-call ownership probe at the MCP layer. - **Expert review.** Tier 2 panel (Backend, Security, Solution Architect). All three independently flagged the upstream-API-not-merged issue as the blocker that triggers this pause. Total tool surface on resume: 13 tools across three resources. 21 acceptance criteria (19 from PREQ + 2 from expert review: integer-ID bounds, shared-validator parity). ## Resume trigger Unpause when a Forgejo release ships REST handlers under the paths above. On resume: 1. Re-verify the merged endpoint shapes against the SREQ's Key Decisions table — paths and payloads may differ from the PR #11761 draft. 2. Pin the minimum Forgejo version in README. 3. Lift the SREQ's "Status: paused" note and move the feature folder from `devwork/backlog/` to `devwork/in-development/`. 4. Run `/develop`. Tracked upstream: - [Forgejo issue #5330 — feat: manage Projects with REST API](https://codeberg.org/forgejo/forgejo/issues/5330) - [Forgejo issue #412 — \[FEAT\] Implement API to retrieve/manage Projects](https://codeberg.org/forgejo/forgejo/issues/412) - [Forgejo PR #11334 — merged, data-model migration (v15)](https://codeberg.org/forgejo/forgejo/pulls/11334) - [Forgejo PR #9384 — closed](https://codeberg.org/forgejo/forgejo/pulls/9384) - [Forgejo PR #11761 — closed](https://codeberg.org/forgejo/forgejo/pulls/11761)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature/issue-13-project-board-tools
No results found.
Labels
Clear labels   
status/paused
Paused pending external dependency or decision

No labels
status/paused
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jbr870/forgejo-mcp-server#13
No description provided.