refactor(server): migrate board view to ForgePort #276
No reviewers
Labels
No labels
area:agents
area:dashboard
area:database
area:design
area:design-review
area:flows
area:infra
area:meta
area:security
area:sessions
area:webhook
area:workdir
security
type:bug
type:chore
type:meta
type:user-story
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
charles/claude-hooks!276
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refactor/migrate-board-to-forgeport"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Second per-consumer Forgejo migration after pipeline (#275). Board shares the same shape surface —
IssueListEntry,PullRequestSummary,PullReview,WorkflowRunSummary— so nothing new needed from the port.Depends on #275. The assignee merge + CI
timed_out/action_requiredfold + milestone forwarding fixes in #275 are implicitly relied on by this migration. Merge order: #275 → this.Changes
board.tsBoardDepssignatures now takeForgePortshapes;PROD_DEPSbuilds aForgejoAdapterper callfoldCiStaterewritten against the port's resolved status enum — no morestatus === "completed" && conclusion === "..."dancefoldReviewStatereads lowercase"approved"/"changes_requested"and takesstring[]for requested reviewersfetchPrStateForReporeads domain fields (pr.headSha,detail.requestedReviewers,detail.mergeable)isUserStory/labelNamescollapse to trivial string-array opsassigneeLoginsimplifies toissue.assignees[0] ?? nullsince the adapter merges singularassigneeinto the plural array!i.pull_requestfilter;api.listRepoIssuesalready setstype=issuesserver-sideTests
board.test.tsfixture helpers returnForgeIssue/ForgePullRequest/ForgeReview/ForgeWorkflowRunpr(),workflowRun(),review()builders keep per-test fixtures terse (same pattern as pipeline test)Checks
bunx tsc --noEmit -p apps/server/tsconfig.json— EXIT=0bun --cwd apps/server test— 1006 pass / 4 pre-existing fails (same as main)Remaining migrations
webhook-handlers.ts— core event dispatchwebhook-ci.ts— CI state machinedeps.ts— dependency graph, DI patternjanitor.ts— impl-seam pattern, 15 fnsagent-runner.ts+foreman.ts→ Claude SDK (Phase 5).Pipeline was the biggest shape-leak site — IssueListEntry, PullRequestSummary, PullReview, WorkflowRunSummary all bled into the view derivation. This commit switches pipeline.ts and its 3 test files to the domain shapes from ForgePort. ### Port extensions surfaced by pipeline usage - `ForgeReview.stale` — Forgejo flags stranded pending requests stale; webhook-ci bounce path (future migration) needs this - `ForgeWorkflowRun.htmlUrl` — pipeline picks the newest run's URL as the stage's "click to see CI" link - `ReviewState` now includes `request_review` — distinct from submitted reviews with state "pending"; the review-stage stall detection needs this to count pending reviewer requests separately ### pipeline.ts changes - `PipelineDeps` signatures take ForgePort shapes; `PROD_DEPS` builds a `ForgejoAdapter` per call and delegates - Adapter's `listIssues` filters out PR-backed rows, so pipeline no longer needs the `!i.pull_request` guard - Derivation logic reads domain fields: `r.reviewer` / `r.state` / `r.commitSha` / `r.submittedAt` instead of `r.user.login` / raw Forgejo strings / `r.commit_id` / `r.submitted_at` - Review-state comparisons use the lowercase enum: `"approved"`, `"changes_requested"`, `"request_review"` - Workflow run status folding rewritten — the port's status field is already the terminal resolution (no separate `conclusion`), so the aggregate logic is simpler - `foldWorkflowRuns` no longer reads `conclusion`; the port's status enum ("success" | "failure" | "in_progress" | …) encodes what conclusion used to ### Tests - `pipeline.test.ts` / `pipeline-stall.test.ts` fixture helpers now construct ForgeIssue / ForgePullRequest / ForgeReview / ForgeWorkflowRun - Added `review()` and `workflowRun()` fixture builders to keep per-test fixtures terse - CI fixtures drop `{status: "completed", conclusion: "success"}` in favour of `workflowRun({status: "success"})` — the port's resolved status eliminates the two-field dance Full server suite: 990 pass / 4 pre-existing fails (3 sweeper JSONL pruning + 1 foreman listSessions flaky). Zero regressions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>