81 lines
1.4 KiB
Markdown
81 lines
1.4 KiB
Markdown
# Issue workflow
|
|
|
|
## Source of truth
|
|
|
|
Gitea Issues are the source of truth for tasks, discussions, labels, milestones, and status.
|
|
|
|
Do not copy the full backlog into git.
|
|
|
|
Repository documents may define:
|
|
|
|
- issue templates
|
|
- triage rules
|
|
- Codex task format
|
|
- verification rules
|
|
- release checklist
|
|
|
|
## Labels
|
|
|
|
Recommended labels:
|
|
|
|
- `P0`
|
|
- `P1`
|
|
- `P2`
|
|
- `P3`
|
|
- `security`
|
|
- `data-integrity`
|
|
- `backend`
|
|
- `frontend`
|
|
- `wiki`
|
|
- `tags`
|
|
- `materials`
|
|
- `theatre`
|
|
- `codex-ready`
|
|
- `needs-design`
|
|
- `blocked`
|
|
- `good-first-codex-task`
|
|
|
|
## Codex-ready criteria
|
|
|
|
An issue can be labeled `codex-ready` only when it has:
|
|
|
|
- clear background
|
|
- target area
|
|
- concrete tasks
|
|
- acceptance criteria
|
|
- verification commands
|
|
- explicit non-goals
|
|
- no unresolved architecture decision
|
|
|
|
## Workflow
|
|
|
|
1. Create or refine the issue in Gitea.
|
|
2. Add labels and milestone.
|
|
3. If design is unclear, label `needs-design`.
|
|
4. Discuss design before implementation.
|
|
5. When scoped enough, label `codex-ready`.
|
|
6. Give Codex the issue URL or copied issue body.
|
|
7. Codex creates a branch.
|
|
8. Codex implements a small patch.
|
|
9. Codex runs verification commands.
|
|
10. Human reviews the diff.
|
|
11. Merge.
|
|
12. Close the issue from the PR/commit message.
|
|
|
|
## Commit message
|
|
|
|
Use issue references when possible:
|
|
|
|
```txt
|
|
fix: prevent preview SSRF
|
|
|
|
Refs: #123
|
|
```
|
|
or
|
|
```
|
|
fix: prevent preview SSRF
|
|
|
|
Closes: #123
|
|
```
|
|
depending on whether the change fully resolves the issue.
|