Jeroen SchweitzerandClaude Opus 4.5
aa3fe916b7
- Add multi-stage Dockerfile (Flutter build → nginx:alpine) - Add nginx.conf with SPA routing, gzip, and caching - Add Gitea workflow for release-triggered builds - Document release procedure in AGENTS.md Deploys to port 8092, auto-updates via Watchtower. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
93 lines
4.5 KiB
Markdown
93 lines
4.5 KiB
Markdown
# LLM Agent Instructions
|
|
|
|
This document contains instructions and documentation references for AI assistants working with this codebase.
|
|
|
|
> **📖 Important**: Before working on this project, read [PHILOSOPHY.md](PHILOSOPHY.md) to understand the system vision, architectural patterns, and design goals. All development should work towards realizing those patterns.
|
|
# AGENTS.md
|
|
|
|
> **Start every session by reading this file.**
|
|
> This file outlines the operational protocols, coding standards, and architectural decisions for this Flutter project.
|
|
|
|
## 1. Agent Operational Protocols
|
|
|
|
### 🧠 Work Patterns (Plan-Act-Reflect)
|
|
* **Plan:** Before writing code, briefly outline your plan. Identify which files you will touch and what the side effects might be.
|
|
* **Act:** Execute the changes in small, atomic steps.
|
|
* **Reflect:** After coding, verify your work. Did you break existing tests? Did you add new tests?
|
|
|
|
### 🌐 Internal Service Access
|
|
* **git.schweitz.net**: Access via `http://localhost:3002` (direct Gitea) to bypass Authentik SSO
|
|
* Example: `curl http://localhost:3002/jpmschweitzer/library-desk/raw/branch/main/README.md`
|
|
* Public repos are readable without authentication
|
|
* Related repos: , `core-api`, `tatlock`, `library-desk`, `scheduler`, `portainer-core`
|
|
|
|
### 🐳 Deployment & Infrastructure
|
|
* **Full stack documentation**: Available in the `portainer-core` repo
|
|
* Access: `curl http://localhost:3002/jpmschweitzer/portainer-core/raw/branch/main/CONTAINERS.md`
|
|
* Contains: All service ports, URLs, Redis DB allocations, external domains
|
|
* **Tatlock deployment**:
|
|
* LAN: `http://192.168.86.149:8000`
|
|
* External: `tatlock.schweitz.net` (behind Authentik SSO)
|
|
* Redis DBs: 1 (memory), 6 (benchmarks)
|
|
* **Health check**: `curl http://192.168.86.149:8000/health`
|
|
|
|
### 🛡️ Git Discipline
|
|
* **Commit Messages:** Use the [Conventional Commits](https://www.conventionalcommits.org/) format.
|
|
* `feat: add user login endpoint`
|
|
* `fix: resolve database connection timeout`
|
|
* `refactor: split monolith dependency file`
|
|
* **Atomic Commits:** Keep commits small. One logical change = one commit.
|
|
* **Version Tagging:** Every version increment (major.minor.patch, not build count) must have a corresponding git tag.
|
|
* Format: `v{major}.{minor}.{patch}` (e.g., `v0.3.0`)
|
|
* Tag after updating `pubspec.yaml` version and CHANGELOG
|
|
* Push tags with `git push --tags`
|
|
|
|
### 🚀 Release Procedure
|
|
|
|
This project uses version-tag-based CI/CD. Releases trigger automated Docker builds and deployments.
|
|
|
|
**Release Steps:**
|
|
|
|
1. Update version in `pubspec.yaml` (bump major.minor.patch, not build number)
|
|
2. Update `CHANGELOG.md` with changes under `## [x.x.x] - YYYY-MM-DD`
|
|
3. Commit changes: `git commit -m "chore: release vX.X.X"`
|
|
4. Create git tag: `git tag vX.X.X`
|
|
5. Push with tags: `git push origin master --tags`
|
|
6. Create release in Gitea UI (git.schweitz.net → Releases → New Release)
|
|
* Select the tag
|
|
* Add release notes (can copy from CHANGELOG)
|
|
* **Publish** the release (this triggers CI/CD)
|
|
|
|
**What happens on release:**
|
|
|
|
* Gitea CI builds Flutter web app in Docker
|
|
* Image pushed to `git.schweitz.internal/jpmschweitzer/tatlock-ui:latest` and `:vX.X.X`
|
|
* Watchtower detects new image and auto-updates running container
|
|
* App available at `http://tower:8092` (and eventually `home.schweitz.net`)
|
|
|
|
**Rollback:**
|
|
|
|
* In Portainer, update image tag to previous version (e.g., `:v0.2.0`)
|
|
* Or: `docker pull git.schweitz.internal/jpmschweitzer/tatlock-ui:v0.2.0`
|
|
|
|
### 🧪 Testing Requirements
|
|
|
|
* **Always add tests for new code before committing.** No exceptions.
|
|
* Tests should cover the happy path and key edge cases.
|
|
* Run `flutter test` before committing to ensure all tests pass.
|
|
* For widgets: use widget tests. For business logic: use unit tests.
|
|
* Code coverage should not decrease with new commits.
|
|
|
|
### 📝 Changelog Maintenance
|
|
|
|
* **Update `CHANGELOG.md`** with every user-facing change.
|
|
* Format: `## [Unreleased] - YYYY-MM-DD` followed by `### Added`, `### Changed`, or `### Fixed`.
|
|
|
|
### 🎨 UI Patterns (MUST READ BEFORE CHANGES)
|
|
|
|
* **Before modifying the widget tree**, read `docs/UI_LAYOUT.md` to understand established patterns.
|
|
* Investigate existing implementations in the codebase before creating new components.
|
|
* **DO NOT** reinvent wheels - check if shared components already exist in `lib/shared/components/`.
|
|
* Look at similar features for reference patterns (e.g., how other list views, forms, or CRUD screens are built).
|
|
* Deviating from established patterns creates inconsistency and technical debt.
|