# AGENTS.md — ForgeBucket AI Agent Guide This file is for AI coding agents (Claude Code, GitHub Copilot, etc.) working in this repository. Read it before making changes. --- ## Mission ForgeBucket is a **unified operating system for software delivery** — not a Git repository viewer with CI attached. The guiding philosophy: > Repositories are runtime systems. The dashboard is a command center. GitOps is first-class. Every feature decision should answer: does this reduce cognitive load? Does this improve operational awareness? Does this improve developer flow? The full product vision lives in [`ai_agent_master_prompt_for_building_modern_git_platform.md`](ai_agent_master_prompt_for_building_modern_git_platform.md). --- ## Architecture Map ``` cmd/forgebucket/ — binary entry point (main.go) internal/ api/ router.go — Chi router, all route definitions (~26 routes) middleware/ — auth, CSRF, RBAC, logging handlers/ — one file per domain (repo, pr, issue, auth, user, ssh...) domain/ git/ — sanitized git binary wrapper (exec.Command only, no shell) federation/ — ActivityPub / ForgeFed (DATA LAYER ONLY — no handlers yet) ci/ — CI orchestrator (EMPTY — Phase 2 stub) models/ — XORM structs + 7 migration files config/ — ENV-driven config, fails fast on missing secrets web/ — //go:embed target for the built React SPA frontend/ src/ pages/ — 20 route-level page components components/ — shared UI (AppShell, Sidebar, Header, DiffViewer, etc.) ui/ tokens.ts — SINGLE SOURCE OF TRUTH for all design tokens hooks/ — custom React hooks api/ — typed API client (fetch wrappers) ``` **Middleware chain — this order is fixed, do not reorder:** ``` Logger → RealIP → Recoverer → CORS → CSRF → SessionAuth → RBAC → Handler ``` --- ## Current Phase Status Understand the phases before adding code — don't build Phase 3 infrastructure when Phase 2 is incomplete. | Phase | Scope | Status | |-------|-------|--------| | 1 | Auth, Git HTTP, repos, PRs, issues, RBAC, webhooks, LFS, design system, 20-page SPA | **Complete** | | 2A | NATS event bus, WebSocket hub upgrade, audit log | **Complete** | | 2B | CI orchestrator, runner manager, Docker executor, artifact registry | **Complete** | | 2C | Pipeline DAG visualization, dashboard CI upgrade, command palette wiring | **Active** | | 3A | Environment model + deployment tracking | Planned | | 3B | Unified operational timeline | Planned | | 3C | Secret management hierarchy | Planned | | 3D | GitOps controller + drift detection | Planned | | 3E | Observability (Prometheus, health sparklines) | Planned | | 3F | Federation handlers (ActivityPub inbox/outbox) | Planned | | 4 | AI diagnostics, signed artifacts, OCI registry, secret/dep scanning | Planned | Do not implement Phase 3+ features without explicit discussion. The `domain/federation/` directory is an intentional stub — the data model exists but no HTTP handlers should be wired until Phase 3F. ### Phase 2C — What's Left to Build All backend APIs for CI are complete. Phase 2C is entirely frontend work: 1. **`types/api.ts`** — `Pipeline` type uses stale fields (`ref`, `status`). Must be updated to match backend (`name`, `filePath`). Add `PipelineRun`, `PipelineJob`, `PipelineStep`, `PipelineStepLog` types. 2. **`queries/pipelines.ts`** — Needs `useRuns`, `useRunDetail`, `useJobLogs`, cancel/retry mutations aligned with correct types. 3. **`GET /api/v1/pipelines/runs`** — A new backend endpoint returning recent runs across all repos owned by the current user (needed by the global `/pipelines` page and dashboard widget). 4. **`PipelinesPage`** — Currently an empty placeholder. Replace with real cross-repo runs list. 5. **`PipelineRunPage`** — New page at `/repos/:owner/:repo/runs/:runId`. Shows run header + DAG + step log viewer. 6. **`PipelineWaterfall`** — Currently uses mock data. Rewrite to accept real `PipelineJob[]` with `needs` dependency graph. 7. **Dashboard CI widget** — Replace hardcoded "Pipeline integration coming soon." with live recent runs. 8. **Command palette** — Add pipeline runs to search results. --- ## Go Conventions ### Git commands — critical rule Always use `exec.Command("git", arg1, arg2, ...)` with **discrete arguments**. Never build a shell string from user input. ```go // CORRECT cmd := exec.Command("git", "clone", "--bare", repoURL, destPath) // WRONG — never do this cmd := exec.Command("sh", "-c", "git clone "+userInput) ``` This rule is non-negotiable. It prevents command injection. ### Router / handlers - Chi router. Route definitions in `internal/api/router.go`. - One handler file per domain area. Keep handlers thin — business logic belongs in domain packages. - All POST/PUT/DELETE routes require `X-CSRF-Token` header matching the session cookie. The middleware enforces this, but don't remove it from routes. ### Database - XORM for all DB access. Structs in `internal/models/`. - Migrations are numbered files in `internal/models/migrations/`. Always add a new migration file; never edit existing ones. - No raw SQL strings built from user input. ### Secrets and config - All secrets come from environment variables via `internal/config/`. - Never hardcode secrets, tokens, or credentials anywhere. - `SESSION_SECRET` ≥ 32 chars. `CSRF_SECRET` = exactly 32 chars. ### Error handling - Return errors up the call stack. Don't swallow them silently. - HTTP handlers use consistent JSON error responses — follow the pattern in existing handlers. --- ## TypeScript / React Conventions ### Design tokens — critical rule All spacing, color, and sizing values must come from `frontend/src/ui/tokens.ts`. Do not introduce new hardcoded pixel values or color hex codes. ```tsx // CORRECT — use token classes via Tailwind