Require a concrete change explanation and explicit user approval before modifying a repository, then implement and verify the approved scope. Use whenever Codex is asked to create, edit, delete, generate, format, refactor, fix, upgrade, or otherwise mutate repository files, dependencies, configuration, tests, documentation, build artifacts, or version-control state.

2026-06-304

repo-map

polkiloo/pacman

Repository layout for the pacman Go PostgreSQL HA cluster manager.

2026-06-174

github-actions-triage

polkiloo/pacman

Use when inspecting GitHub Actions, CI failures, failed Go tests, workflow logs, or build/lint/test errors. Avoid reading full logs; summarize failed jobs and inspect only relevant snippets.

2026-06-144

api-contract

polkiloo/pacman

Maintain PACMAN-native and Patroni-compatible API contracts.

2026-06-144

cluster-state-machine

polkiloo/pacman

PACMAN domain rules for cluster state transitions and operation history.

2026-06-144

control-plane-quorum

polkiloo/pacman

Rules for PACMAN control-plane quorum, leases, epochs, fencing, and split-brain prevention.

2026-06-144

name	pr-review-checklist
description	Lightweight review checklist for Go HA and distributed-systems code.

PR Review Checklist

Lead with correctness risks and file/line findings. Keep summaries brief.

Check:

State transitions are explicit, validated, and persisted where required.
Failover/switchover/rejoin paths preserve epoch, role, timeline, and history invariants.
Quorum and lease decisions have a single source of truth and avoid split brain.
Fencing-aware code fails closed when fencing is required but unavailable.
Concurrency uses contexts, cancellation, deadlines, and bounded retries.
Operations are idempotent across retries and process restarts.
PostgreSQL actions verify role, timeline, LSN, replication, and recovery state before destructive steps.
API changes keep handlers, models, OpenAPI docs, compatibility responses, and tests aligned.
Logs/metrics include enough identifiers to debug cluster decisions.
Tests cover failure paths, stale state, retry behavior, and contract edges.

Do not spend review budget on broad refactors unless they affect safety, operability, or the requested change.