.openhands/microagents/repo.md

name, type, agent

name	type	agent
Agiliton environment	repo	CodeActAgent

You are running inside Agiliton's infrastructure. The code you work on is delegated to you via Jira tickets assigned to the openhands account. A cron poller (oh-jira-poll) claimed the ticket and fired the conversation; you should not touch the Jira workflow yourself — it's handled externally.

What's available to you

You have bash, Python, a filesystem editor, and a browser. Plus these internal HTTP services reachable on the sandbox's host network:

Learnings database (pgvector)

URL: http://localhost:9221 (learning-mcp REST shim). Use this to look up prior gotchas, fixes, and conventions before reimplementing something the team already solved.

Search semantically:

curl -sf -X POST http://localhost:9221/api/search \
  -H 'Content-Type: application/json' \
  -d '{"query": "<natural-language question>", "limit": 5}' \
  | jq '.text'

Record a new learning (do this when you discover a non-obvious fix worth keeping):

curl -sf -X POST http://localhost:9221/api/insert \
  -H 'Content-Type: application/json' \
  -d '{"category":"gotcha|fix|convention","content":"<lesson>","tags":["tag1"]}'

Sentry issues

URL: http://localhost:9215 (sentry-mcp REST shim).

List recent issues for the project you're touching:

curl -sf -X POST http://localhost:9215/api/list_issues \
  -H 'Content-Type: application/json' \
  -d '{"project":"<slug>","statsPeriod":"24h","limit":10}' | jq

Get a single issue with stack trace:

curl -sf -X POST http://localhost:9215/api/get_issue \
  -H 'Content-Type: application/json' \
  -d '{"issueId":"<id>"}' | jq

Use these when your ticket mentions a Sentry error ID, or when you want to verify a fix actually matches the stack trace.

Gitea

Host: https://git.agiliton.cloud. Auth via $GITEA_TOKEN (already in env as an OH custom secret). Use it both for cloning (https://x-access-token:${GITEA_TOKEN}@git.agiliton.cloud/...) and for PR creation via the Gitea REST API (POST /api/v1/repos/{owner}/{repo}/pulls). Do NOT push to main — branch protection will reject; always push to oh/<TICKET-KEY> and open a PR.

What's NOT available to you

• No Atlassian MCP — do not try to read, comment on, or transition Jira tickets. The poller handles the handback automatically when it sees your PR. The ticket description you were given is the full specification.
• No vault / secrets store — never ask for credentials beyond $GITEA_TOKEN.
• No deploy / infra / SSH access — propose changes via code, never run deploys.
• No access to the CI platform — if tests pass in the repo locally, that's your signal.

Working style

• Keep diffs minimal and scoped to the ticket. No opportunistic refactoring.
• Before implementing, spend one search call on the learnings DB for the domain in question — past gotchas often save you from dead-ends.
• If a Sentry issue is referenced in the ticket, fetch its stack trace before writing the fix.
• Don't write multi-paragraph docstrings or decision-log comments. Well-named identifiers speak for themselves.
• When you finish, open the PR and stop. Do not merge. Do not touch Jira.