---
module: processes.gitea-issues
title: Gitea Issue Process
tab: Overview
order: 10
audience: bcos
---

How we track work in Gitea. **BCOS admin only.** Git hosting is **Gitea** (not GitHub/GitLab).

## Issue first — always
**Any work, however phrased ("just do X", "develop Y"), gets a Gitea issue created BEFORE code.**
No issue = don't start. Before fixing a bug, **search the repo's open `Bug`s first** — one may
already exist (avoid duplicates).

## Labels (org-level, shared across all `hiveiq-src` repos)
- **Type:** `Bug`, `Feature`, `Enhancement`, `Breaking`, `Documentation`, `Security`, `Testing`
- **Priority:** `Priority/Critical` · `High` · `Medium` · `Low`
- **Review/Triage:** `Reviewed/Confirmed` · `Duplicate` · `Invalid` · `Won't Fix`
- **Status:** `Status/Blocked` · `Need More Info` · `Abandoned`
- **Workflow:** `Verify Fix` (fix deployed, verify before closing) · `Reopen` (regressed) ·
  `Tested/Not Fixed`

## Assignment
- **New issue** → assign `hiveiq` (triage / fix owner).
- **Fix deployed** → reassign to the verifier and apply **`Verify Fix`**.
  - **Frontend** fixes → **tristan** (QA). **Backend** fixes → **johannes** (tristan can't test backend).
  - `erin` has no Gitea account yet — assign only `tristan` until she does.

## Closing — always manual (and it now notifies the reporter)
**Never close an issue via the API.** Claude applies labels and comments only. The team closes
issues in the Gitea UI after verification. Never PATCH `state: closed`.

> **Closing an issue auto-notifies the reporter.** A Gitea webhook (`gitea-notify`, built by
> dlx-claude 2026-07-01) sends the reporter a DIRECT message in their HiveIQ inbox when an issue is
> closed — using the **Resolution** field from the issue template. **Fill in the Resolution before
> closing** so the customer gets a meaningful message. (Reporter email is read from the issue body;
> if they're not a HiveIQ user, the notification is silently skipped.)

## A fix isn't done until its issue is reconciled
After deploying a fix: **comment the fix on the matching issue + apply `Verify Fix` + assign the
verifier.** Never leave a deployed fix with a stale/untouched issue.

## PR approval (ties to [[processes.main]])
Johannes approves the PR in the Gitea UI (SOC2 gate) — never Claude. After approval, Claude merges
via API.

## API note
Create/label/assign via the Gitea REST API with the `hiveiq` token. `directlx` = human reviewer
(Johannes). Use `GIT_SSL_NO_VERIFY=true` for Gitea calls (self-signed internal cert).
