relay: Instructions file for Codex

Git Workflow Rules

NEVER Push Directly to Main

CRITICAL: Agents must NEVER push directly to the main branch.

• Always work on a feature branch
• Commit and push to the feature branch only
• Let the user decide when to merge to main
• Do not merge to main without explicit user approval

# CORRECT workflow
git checkout -b feature/my-feature
# ... do work ...
git add .
git commit -m "My changes"
git push origin feature/my-feature
# STOP HERE - let user merge

# WRONG - never do this
git checkout main
git merge feature/my-feature
git push origin main  # NO!

This ensures the user maintains control over what goes into the main branch.

Changelog

Curate [Unreleased] in CHANGELOG.md as you land PRs. The root changelog is the cross-package, user-facing release narrative for Relay. It follows Keep a Changelog and Semantic Versioning.

An empty post-release changelog starts with [Unreleased]. The first pending user-visible change must set the heading to [Unreleased - Patch], [Unreleased - Minor], or [Unreleased - Major] according to its SemVer impact. The pending release level is monotonic (Patch < Minor < Major): raise the heading when a higher-impact change arrives; never lower it for a later lower-impact change, and leave it unchanged for another change at the same level. When a release is cut, move the pending entries under the released version and restore an empty [Unreleased] heading with no release level.

Changelog entries should be concise and impact-first. Prefer one short bullet per user-visible change: name the command, API, schema, or package touched and the practical effect. Drop issue/PR links, internal review notes, implementation backstory, release-only entries, and "foundation for..." phrasing unless that text clearly explains the shipped impact.

Use Keep a Changelog sections (Added, Changed, Deprecated, Removed, Fixed, Security), plus Breaking Changes and Migration Guidance when a SemVer-major change needs explicit callouts. Do not use generated perspective sections such as "Product Perspective", "Technical Perspective", or "Releases". Do not add web-only changes to the changelog. Omit unpublished or withdrawn versions as release headings; move their shipped user-visible changes into the corrected published release.