no-mistakes AGENTS.md

AGENTS.md

This file is for agentic coding tools working in this repo.

This repository is a Go CLI app named no-mistakes. The binary entrypoint is cmd/no-mistakes; implementation code lives under internal/, and the package names there are the layout map (CLI in internal/cli, daemon in internal/daemon, pipeline and steps in internal/pipeline, agent adapters in internal/agent, terminal UI in internal/tui, shared infrastructure in internal/git, internal/ipc, internal/config, internal/db, internal/paths, internal/types). Build, test, and release commands are owned by the Makefile; read it for the full target list instead of relying on a copy here.

Safest local verification sequence after non-trivial changes:

• gofmt -w .
• make lint (generated-skill drift check plus go vet)
• go test -race ./... (the e2e suite is behind the e2e build tag and excluded)
• make e2e when touching agent integrations, the e2e harness, or recorded fixtures
• go build -o ./bin/no-mistakes ./cmd/no-mistakes

GitLab Backend (internal/scm/gitlab)

• The backend is pinned against glab v1.5x, whose flag surface drifts between versions: the auth check must be host-scoped (--hostname <host>, falling back to unscoped only when the host is unknown), glab mr list no longer accepts --state opened, glab mr update has no -y/--yes flag at all (unlike mr create, which does, so UpdatePR must not pass it), and the daemon's detached-HEAD worktree breaks glab ci get, so pipeline jobs are read via the branch-independent glab api .../pipelines/<id>/jobs REST endpoint.
• The comments in internal/scm/gitlab/gitlab.go own the full rationale for each trap; extend them there when you hit new glab version drift.

Gitea Backend (internal/scm/gitea)

• Verified empirically against a real tea 0.15.1 CLI and a real Gitea 1.27.2 + Actions instance (Docker/Podman gitea/gitea + gitea/act_runner), not guessed from docs. tea whoami has no --login flag (unlike every other tea entity subcommand), so Host.Available scopes its check through tea api --login <name> /user instead - the same host-scoping purpose as glab's --hostname.
• tea actions runs view --jobs --output json does NOT emit clean structured JSON: --output json renders the run header as plain text and only the trailing jobs array is real JSON, and that array carries status (queued/in_progress/completed) but no conclusion (success/failure/...) at the job level. Job-level pass/fail is read from the REST endpoint (GET /repos/{owner}/{repo}/actions/runs/{run}/jobs, which does carry status + conclusion) reached through tea api, which reuses tea's own stored login/token - no separate HTTP client or credential needed.
• tea pulls list --output json renders every field (including index and mergeable) as a JSON string, while tea pulls <idx> --output json (single-PR view) renders the same fields with native JSON types (index an int, mergeable/hasMerged bools). The two response shapes are genuinely different structs in gitea.go; do not unify them.
• tea pulls create has no --output json flag and echoes the PR body into its human-readable stdout, so a body containing an http(s):// URL can defeat a naive "first URL line" scrape. CreatePR re-lists the PR by head branch via tea pulls list for a structured result instead of parsing create's own output; scraping stdout is only a last-resort fallback.
• tea pulls edit has no --base flag (unlike tea pulls create --base). Retargeting uses tea api --method PATCH --field base=<branch> on /repos/{owner}/{repo}/pulls/{index}; omitting --method would POST because a body defaults tea api to POST. FindPR copies item.Base onto scm.PR.BaseBranch so a per-run override can see the live forge base.
• tea infers "which Gitea instance" from the current directory's git remote, which the daemon's detached bare-gate repo never has, so every invocation carries --login <name> explicitly. The login name is resolved from tea's own config.yml by host (scm.ResolveGiteaLogin), mirroring glabKnowsHost/ghKnowsHost for detection.
• Capabilities().MergeableState is declined (matching Bitbucket): Gitea's PR mergeable field has a documented upstream bug (go-gitea/gitea#25849) that can stick false after a conflict is actually resolved.
• tea actions runs list's array order is not documented as newest-first, and a branch can have more than one run sharing the same head SHA (e.g. a manual UI re-run), so GetChecks/FetchFailedCheckLogs select the run via mostRecentRun (highest numeric run ID) rather than trusting list order or index [0].
• The comments in internal/scm/gitea/gitea.go own the full rationale for each trap.