|
1 | | -# sure-aio Agent Notes |
| 1 | +# AGENTS.md |
2 | 2 |
|
3 | | -`sure-aio` packages Sure as a single Unraid-friendly container with internal PostgreSQL and Redis. |
| 3 | +This repository is part of a broader portfolio of Unraid-first AIO projects. |
4 | 4 |
|
5 | | -## Runtime Shape |
| 5 | +## Repository intent |
6 | 6 |
|
7 | | -- Web app: Sure Rails app |
8 | | -- Background jobs: Sidekiq worker |
9 | | -- Database: internal PostgreSQL |
10 | | -- Cache/queue: internal Redis |
11 | | -- Supervision: `s6-overlay` |
| 7 | +- This repo packages an opinionated, beginner-friendly Unraid AIO deployment. |
| 8 | +- Default behavior should optimize for a reliable first boot on Unraid. |
| 9 | +- Advanced users should retain escape hatches where supported. |
12 | 10 |
|
13 | | -## Important Behavior |
| 11 | +## Engineering expectations |
14 | 12 |
|
15 | | -- This repo is intentionally beginner-first: one container, one appdata path, no external database required by default. |
16 | | -- Redis runtime permissions matter because Unraid bind mounts can break ownership assumptions. |
17 | | -- Database preparation was moved away from a fragile standalone oneshot path and into the runtime flow that actually boots the app. |
18 | | -- Worker startup should wait for web readiness rather than racing app boot. |
| 13 | +- Prefer consistency with `unraid-aio-template` over one-off repo behavior. |
| 14 | +- Keep CI and release behavior aligned with the rest of the AIO fleet. |
| 15 | +- Respect protected branches and use PR-based automation for external sync flows. |
| 16 | +- Favor operational clarity over cleverness. |
19 | 17 |
|
20 | | -## CI And Publish Policy |
| 18 | +## Release model |
21 | 19 |
|
22 | | -- Validation and smoke tests should run on PRs and branch pushes. |
23 | | -- Publish should happen only from the default branch. |
24 | | -- GHCR image naming must stay lowercase. |
| 20 | +- Container packages publish automatically from `main`. |
| 21 | +- Formal changelog updates and GitHub Releases are release-driven. |
| 22 | +- Releases use `upstream version + aio revision`, for example `v0.6.8-aio.1`. |
| 23 | +- Keep changelog-friendly Conventional Commit titles and PR titles. |
25 | 24 |
|
26 | | -## What To Preserve |
| 25 | +## Unraid expectations |
27 | 26 |
|
28 | | -- Keep the Unraid XML contract stable unless there is a strong reason to change user-facing setup. |
29 | | -- Public docs should stay product-facing and beginner-friendly. |
30 | | -- Smoke tests should cover first boot, restart, and persistence. |
| 27 | +- Unraid-facing XML/icon assets should stay aligned with `awesome-unraid`. |
| 28 | +- User-facing metadata should remain accurate: |
| 29 | + - `Project` |
| 30 | + - `Support` |
| 31 | + - `TemplateURL` |
| 32 | + - `Icon` |
| 33 | + - `Overview` |
| 34 | + - `Category` |
31 | 35 |
|
32 | | -## Known Good Pattern |
| 36 | +## Documentation expectations |
33 | 37 |
|
34 | | -- Local smoke testing should verify the running service, not brittle host-side file assumptions. |
35 | | -- If CI flaps, prefer making readiness checks more robust instead of weakening coverage. |
| 38 | +- Be explicit about operational tradeoffs. |
| 39 | +- Do not imply the AIO model removes inherent complexity from the upstream software. |
| 40 | +- Keep beginner defaults simple, but document power-user override paths where they exist. |
0 commit comments