hrynco-ef/AGENTS.md

hrynco-ef Agent Rules

This file is the authoritative source for hrynco-ef workflow, delivery, and role rules.

1. Startup

• Command timeout: if a command runs longer than 10 minutes, report timeout and ask the user.
• Validate required services before task work:
  • Gitea authenticated access and the hrynco/hrynco-ef repo
  • TeamCity authenticated access
• If any startup check fails, stop and ask the user.

Operational cadence

• TeamCity polling: do not poll more often than once every 30 seconds.
• If no relevant build is visible after 60 seconds, warn once and continue waiting normally.
• Play the completion sound after multi-step work.
• Play the question sound before or with any blocking user question.

Startup report

Print one startup report line per check:

• ✅ success, ⚠️ failure
• include a service emoji on every line
• use bright colors when supported
• after all checks, print ✅ or ⚠️ for initialization

Required report items:

• Workflow rules loaded
• Gitea auth + reachability
• Gitea resource access (hrynco/hrynco-ef)
• TeamCity auth + reachability
• Initialization

2. Workflow

• AGENTS.md is the source of truth; treat other docs as references only.
• Do not start a new task before the current one is complete.
• Default development branch: development.
• Before task work:
  • be on local development
  • local development must be clean
  • local development must match remote
  • if not, fix that first
• On task start:
  • create a Gitea issue in hrynco/hrynco-ef if one does not exist
  • create a feature branch from development
  • name the branch after the task
• Work only in the feature branch.
• Keep diffs small, targeted, and consistent with existing style.
• Do not merge or publish during development.

Issue lifecycle

1. Product analyst creates/refines the Gitea issue.
2. Developer takes the issue and starts implementation.
3. Developer finishes implementation and hands off to code review.
4. Code reviewer reviews and either passes or returns to developer.
5. Repeat developer/reviewer cycles as needed.
6. Maximum five review rounds total for the same unresolved issue state.
7. After review round five, if still unresolved, return to product analysis.
8. Tester validates the implementation against acceptance criteria.
9. Developer waits for user validation approval.
10. Delivery and release manager handles commit, push, PRs, merge, and TeamCity publish validation.

Task rules

• Create the Gitea issue before development starts.
• Default assignee is AI unless the task flow requires another assignee.
• Define scope and acceptance criteria.
• Tasks must be independently deliverable and testable.

3. Validation

• Build before finishing.
• Run relevant tests and checks.
• Verify no regressions.
• Do not guess about validation; use actual evidence.

4. Completion

After explicit user validation approval:

• commit staged changes
• push the feature branch
• create PR from feature branch to development
• merge that PR
• do not merge to main unless a new NuGet package release is explicitly requested
• when a release is requested: create PR from development to main, merge, wait for TC HrynCo / HrynCo.EF / publish to finish successfully
• close the Gitea issue
• switch back to development
• pull latest development
• ensure local development matches remote
• leave the repository in a clean end state

Spent Time

• Do not track spent time — this repo uses Gitea, not YouTrack.

Command output

• Keep command summaries concise.
• Do not dump raw output unless needed for diagnosis or explicitly requested.

5. Communication

• Keep command output summaries concise.
• Do not dump raw command output unless needed.
• Use direct links to Gitea issues and wiki pages in implementation notes when stable links exist.
• Use emojis intentionally for scanning, not mechanically.
• Commit messages must be Conventional Commit style, lowercase subject, short body.

6. Audio

• Play C:\Sounds\AgentSounds\warcraft_2_jobs_done.mp3 after multi-step work completes.
• Play C:\Sounds\AgentSounds\peasantdeath.mp3 before or with any blocking user question.
• Use System.Windows.Media.MediaPlayer for MP3 playback on Windows.

7. Engineering

• This repo publishes two NuGet packages: HrynCo.DAL.Abstract and HrynCo.DAL.EF.
• Package versions are injected by TeamCity at build time via Directory.Build.props.
• Packages are pushed to nuget.org by the HrynCo / HrynCo.EF / publish TC build.
• Do not hardcode versions in .csproj files.
• Directory.Packages.props centralizes all dependency versions.
• Keep HrynCo.DAL.Abstract free of EF Core dependencies — it must remain infrastructure-agnostic.
• HrynCo.DAL.EF may depend on EF Core and HrynCo.DAL.Abstract.

8. Role rules

Developer

• Implement end to end.
• Do not leave partial work.
• Do not refactor unrelated code.
• Validate before finishing.

Code reviewer

• Focus on correctness, regressions, security, and missing tests.
• Report only meaningful findings.
• Do not modify code.

Product analyst

• Make tasks clear, scoped, and executable.
• Avoid implementation assumptions unless necessary.

Tester

• Validate happy path, failure path, and adjacent regressions.
• Report exact steps, actual result, expected result, and severity.

Delivery and release manager

• Handle PR flow and publish validation.
• Do not trigger the publish build manually — it runs automatically on merge to main.
• Mark delivered only after TC publish build succeeds.