vision(#623): disinto-chat escalation tools (CI run, issue create, PR create) #712

Closed
opened 2026-04-11 23:24:51 +00:00 by dev-bot · 6 comments
Collaborator

Goal

Let disinto-chat perform scoped write actions against the factory — specifically: trigger a Woodpecker CI run, create a Forgejo issue, create a Forgejo PR — via explicit backend endpoints. The UI surfaces these as buttons the user clicks from a chat turn that proposes an action. The model never holds API tokens directly.

Why

  • #623 lists these escalations as the difference between "chat that talks about the project" and "chat that moves the project forward".
  • Routing through explicit backend endpoints (instead of giving the sandboxed claude process API tokens) keeps the trust model tight: the user authorises each action, not the model.

Scope

Files to touch

  • docker/chat/server.{py,go} — new authenticated endpoints (reuse #708 / #709 session check):
    • POST /chat/action/ci-run — body {repo, branch} → calls Woodpecker API with WOODPECKER_TOKEN (already in .env from existing factory setup) to trigger a pipeline.
    • POST /chat/action/issue-create — body {title, body, labels} → calls Forgejo API /repos/<owner>/<repo>/issues with FORGE_TOKEN.
    • POST /chat/action/pr-create — body {head, base, title, body} → calls /repos/<owner>/<repo>/pulls.
    • All actions record to #710's NDJSON history as {role: "action", ...} lines.
  • docker/chat/ui/index.html — small HTMX pattern: when claude's response contains a marker like <action type="issue-create">{...}</action>, render a clickable button below the message; clicking POSTs to /chat/action/<type> with the payload.
  • lib/generators.sh chat env: pass WOODPECKER_TOKEN, FORGE_TOKEN, FORGE_URL, FORGE_OWNER, FORGE_REPO.

Out of scope

  • Destructive actions (branch delete, force push, secret rotation) — deliberately excluded.
  • Multi-step workflows / approval chains.
  • Arbitrary code execution in the chat container (that is what the agents exist for).

Affected files

  • docker/chat/server.py (or server.go) — new action endpoints
  • docker/chat/ui/index.html — action button rendering
  • lib/generators.sh — pass additional env vars to chat container

Acceptance

  • A chat turn that emits an <action type="issue-create">{...}</action> block renders a button; clicking it creates an issue on Forgejo, visible via the API.
  • CI-trigger action creates a Woodpecker pipeline that can be seen in the CI UI.
  • PR-create action produces a Forgejo PR with the specified head / base.
  • All three actions are logged into the #710 history file with role action and the response from the API call.
  • Unauthenticated requests to /chat/action/* return 401 (inherits #708 gate).

Depends on

  • #708 (OAuth gate — actions are authorised by the logged-in user).
  • #742 (CI smoke test fix — #712 fails CI until agent-smoke.sh lib sourcing is stabilised)
  • #710 (history — actions need to be logged alongside chat turns).

Notes

  • Forgejo API auth: the factory's FORGE_TOKEN is a long-lived admin token. For MVP, reuse it; a follow-up issue can scope it down to per-user Forgejo tokens derived from the OAuth flow.
  • Woodpecker API is at http://woodpecker:8000/api/..., reachable via the compose network — no need to go through the edge container.
  • The <action> marker is deliberately simple markup the model can emit in its response text. Do not implement tool-calling protocol; do not spin up an MCP server.

Boundaries for dev-agent

  • Do not give the claude subprocess direct API tokens. The chat backend holds them; the model only emits action markers the user clicks.
  • Do not add destructive actions (delete, force-push). Additive only.
  • Do not invent a new markup format beyond <action type="...">{JSON}</action>.
  • Parent vision: #623.
## Goal Let `disinto-chat` perform scoped write actions against the factory — specifically: trigger a Woodpecker CI run, create a Forgejo issue, create a Forgejo PR — via explicit backend endpoints. The UI surfaces these as buttons the user clicks from a chat turn that proposes an action. The model never holds API tokens directly. ## Why - #623 lists these escalations as the difference between "chat that talks about the project" and "chat that moves the project forward". - Routing through explicit backend endpoints (instead of giving the sandboxed claude process API tokens) keeps the trust model tight: the *user* authorises each action, not the model. ## Scope ### Files to touch - `docker/chat/server.{py,go}` — new authenticated endpoints (reuse #708 / #709 session check): - `POST /chat/action/ci-run` — body `{repo, branch}` → calls Woodpecker API with `WOODPECKER_TOKEN` (already in `.env` from existing factory setup) to trigger a pipeline. - `POST /chat/action/issue-create` — body `{title, body, labels}` → calls Forgejo API `/repos/<owner>/<repo>/issues` with `FORGE_TOKEN`. - `POST /chat/action/pr-create` — body `{head, base, title, body}` → calls `/repos/<owner>/<repo>/pulls`. - All actions record to #710's NDJSON history as `{role: "action", ...}` lines. - `docker/chat/ui/index.html` — small HTMX pattern: when claude's response contains a marker like `<action type="issue-create">{...}</action>`, render a clickable button below the message; clicking POSTs to `/chat/action/<type>` with the payload. - `lib/generators.sh` chat env: pass `WOODPECKER_TOKEN`, `FORGE_TOKEN`, `FORGE_URL`, `FORGE_OWNER`, `FORGE_REPO`. ### Out of scope - Destructive actions (branch delete, force push, secret rotation) — deliberately excluded. - Multi-step workflows / approval chains. - Arbitrary code execution in the chat container (that is what the agents exist for). ## Affected files - `docker/chat/server.py` (or `server.go`) — new action endpoints - `docker/chat/ui/index.html` — action button rendering - `lib/generators.sh` — pass additional env vars to chat container ## Acceptance - [ ] A chat turn that emits an `<action type="issue-create">{...}</action>` block renders a button; clicking it creates an issue on Forgejo, visible via the API. - [ ] CI-trigger action creates a Woodpecker pipeline that can be seen in the CI UI. - [ ] PR-create action produces a Forgejo PR with the specified head / base. - [ ] All three actions are logged into the #710 history file with role `action` and the response from the API call. - [ ] Unauthenticated requests to `/chat/action/*` return 401 (inherits #708 gate). ## Depends on - #708 (OAuth gate — actions are authorised by the logged-in user). - #742 (CI smoke test fix — #712 fails CI until agent-smoke.sh lib sourcing is stabilised) - #710 (history — actions need to be logged alongside chat turns). ## Notes - Forgejo API auth: the factory's `FORGE_TOKEN` is a long-lived admin token. For MVP, reuse it; a follow-up issue can scope it down to per-user Forgejo tokens derived from the OAuth flow. - Woodpecker API is at `http://woodpecker:8000/api/...`, reachable via the compose network — no need to go through the edge container. - The `<action>` marker is deliberately simple markup the model can emit in its response text. Do not implement tool-calling protocol; do not spin up an MCP server. ## Boundaries for dev-agent - Do not give the claude subprocess direct API tokens. The chat backend holds them; the model only emits action markers the user clicks. - Do not add destructive actions (delete, force-push). Additive only. - Do not invent a new markup format beyond `<action type="...">{JSON}</action>`. - Parent vision: #623.
dev-bot added the
backlog
label 2026-04-11 23:24:51 +00:00
planner-bot added the
priority
label 2026-04-12 03:33:52 +00:00
dev-qwen self-assigned this 2026-04-12 03:50:38 +00:00
dev-qwen added
in-progress
and removed
backlog
labels 2026-04-12 03:50:38 +00:00
Collaborator

Blocked — issue #712

Field Value
Exit reason ci_exhausted
Timestamp 2026-04-12T04:10:59Z
### Blocked — issue #712 | Field | Value | |---|---| | Exit reason | `ci_exhausted` | | Timestamp | `2026-04-12T04:10:59Z` |
dev-qwen added
blocked
and removed
in-progress
labels 2026-04-12 04:10:59 +00:00
planner-bot added
backlog
and removed
blocked
labels 2026-04-12 05:45:42 +00:00
Collaborator

Planner run 6: Relabeled blockedbacklog,priority for ci_exhausted retry. Sub-issue 10/10 for #623 (has stale PR #733). If CI fails again on retry, may need investigation into what specifically is failing.

**Planner run 6:** Relabeled `blocked` → `backlog,priority` for ci_exhausted retry. Sub-issue 10/10 for #623 (has stale PR #733). If CI fails again on retry, may need investigation into what specifically is failing.
dev-qwen added
in-progress
and removed
backlog
labels 2026-04-12 05:47:20 +00:00
Author
Collaborator

Blocked — issue #712

Field Value
Exit reason ci_exhausted_poll (3 attempts, PR #733)
Timestamp 2026-04-12T05:49:03Z
### Blocked — issue #712 | Field | Value | |---|---| | Exit reason | `ci_exhausted_poll (3 attempts, PR #733)` | | Timestamp | `2026-04-12T05:49:03Z` |
dev-bot added
blocked
and removed
in-progress
labels 2026-04-12 05:49:03 +00:00
Collaborator

Blocked — issue #712

Field Value
Exit reason ci_exhausted
Timestamp 2026-04-12T06:05:02Z
### Blocked — issue #712 | Field | Value | |---|---| | Exit reason | `ci_exhausted` | | Timestamp | `2026-04-12T06:05:02Z` |
dev-bot added
backlog
and removed
blocked
labels 2026-04-14 20:52:17 +00:00
dev-qwen was unassigned by dev-bot 2026-04-14 20:52:17 +00:00
dev-bot self-assigned this 2026-04-14 20:52:17 +00:00
dev-bot was unassigned by planner-bot 2026-04-15 02:39:36 +00:00
Collaborator

Planner run 8: Cleared stale dev-bot assignment. CI root cause (#742) is fixed — PR #754 merged. Ready for dev-agent retry. Prior ci_exhausted failures were systemic, not issue-specific. Existing PR #733 may need rebase or fresh branch.

**Planner run 8:** Cleared stale dev-bot assignment. CI root cause (#742) is fixed — PR #754 merged. Ready for dev-agent retry. Prior ci_exhausted failures were systemic, not issue-specific. Existing PR #733 may need rebase or fresh branch.
dev-bot self-assigned this 2026-04-15 06:52:23 +00:00

this is not needed, the agent should just use the disinto x tools on the host

this is not needed, the agent should just use the disinto x tools on the host
Sign in to join this conversation.
No milestone
No project
No assignees
4 participants
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: disinto-admin/disinto#712
No description provided.