chore: update AGENTS.md

This commit is contained in:
cogwheel0
2025-09-16 12:58:02 +05:30
parent 7e6009d2cc
commit 3457fd6478
2 changed files with 21 additions and 328 deletions

159
AGENTS.md
View File

@@ -1,143 +1,26 @@
# AGENTS.md
# Repository Guidelines
Guidelines for AI coding agents working in this repository. Follow these guardrails to make safe, minimal, and effective changes.
## Project Structure & Module Organization
- `lib/` hosts Flutter code: `core/` for services, `features/` for screens and flows, `shared/` for reusable UI, `l10n/` for generated localization, and `main.dart` as the bootstrap entry.
- `assets/` contains bundled media referenced in `pubspec.yaml`; platform bits live inside `android/` and `ios/`. Release collateral is under `fastlane/`, while helper scripts sit in `scripts/`.
## Purpose
## Build, Test, and Development Commands
- `flutter pub get` installs pub dependencies after manifest edits.
- `flutter pub run build_runner build --delete-conflicting-outputs` regenerates serializers and other codegen output.
- `flutter run -d <device>` launches a debug build against an emulator or physical device (`-d ios`, `-d android`).
- `flutter analyze` executes static analysis checks; fix warnings before committing.
- `flutter build apk --release`, `flutter build appbundle --release`, and `flutter build ios --release` assemble store packages.
- `./scripts/release.sh` orchestrates the tagged release workflow once CI succeeds.
- Define how agents contribute changes safely to this Flutter mobile app.
- Provide projectspecific commands, structure, and do/dont rules.
- Ensure consistency with existing code style and workflows.
## Coding Style & Naming Conventions
- Use Flutter defaults: two-space indentation, `lowerCamelCase` for members, `UpperCamelCase` for types, and snake_case filenames across `lib/` and `test/`.
- Format code with `dart format .` and rely on `flutter analyze` to enforce `package:flutter_lints` (see `analysis_options.yaml`). Avoid `print`; prefer injected loggers or platform channels.
## Guardrails
- Minimal, targeted changes only; dont refactor broadly without a clear reason.
- Dont edit generated files or vendored sources (see “Do Not Edit” list).
- Dont introduce new dependencies without a clear justification.
- Dont commit secrets, tokens, or credentials. Use env/config only.
- Dont change licensing headers or LICENSE.
- Prefer surgical fixes over sweeping rewrites; match existing patterns.
- Update or add documentation when behavior changes.
## Project Overview
- Stack: Flutter/Dart mobile app for interacting with OpenWebUI.
- Notable packages: `flutter_riverpod`, `dio`, `freezed`, `json_serializable`, `flutter_secure_storage`.
- Codegen: `build_runner` (freezed/json_serializable) and Flutter genl10n.
- State management: Riverpod.
## Key Commands
Run from repository root.
```bash
# Install deps
flutter pub get
# Generate code (freezed/json_serializable)
flutter pub run build_runner build --delete-conflicting-outputs
# Localization codegen (auto during run/build)
flutter gen-l10n
# Analyze & format
flutter analyze
dart format .
# Run app (pick a platform)
flutter run -d ios
flutter run -d android
# Build release artifacts
flutter build apk --release
flutter build appbundle --release
flutter build ios --release
```
## Repository Structure (highlevel)
```
lib/
core/ # models, services, providers, utils
features/ # featurescoped UI/logic (auth, chat, server, settings)
l10n/ # ARB + generated localization
shared/ # shared widgets, theme, utils
```
Follow existing folder conventions when adding code. Prefer feature folders for new UI or logic.
## Code Generation
- Freezed/JSON: run `flutter pub run build_runner build --delete-conflicting-outputs` after changes to models/DTOs.
- Localization: edit ARB files and run `flutter gen-l10n` (or `flutter run`). See `docs/localization.md`.
## Do Not Edit (Generated/Vendored)
- `build/`
- `lib/l10n/app_localizations*.dart` (generated by genl10n)
- `openwebui-src/` (vendored upstream; only update by syncing from upstream, not adhoc edits)
- Any other generated files created by build tools
If a change appears necessary to a generated file, modify its source (e.g., ARB or model) and regenerate.
## Patterns & Style
- Riverpod: prefer providers/notifiers consistent with existing usage.
- Networking: use the shared `Dio` provider and interceptors if present.
- Models: use `freezed`/`json_serializable` patterns matching current models.
- UI: reuse shared widgets where possible; keep styling consistent.
- Null safety: follow strict nullsafety conventions already in the codebase.
- Lints: keep `flutter analyze` clean; fix warnings you introduce.
## Validation Checklist (before opening a PR)
- Ran `flutter pub get` and codegen commands.
- App compiles and runs on at least one target (`ios` or `android`).
- `flutter analyze` passes with no new issues.
- Updated docs/README if behavior or setup changed.
- No changes to generated/vendored files.
- No secrets, tokens, or credentials added to the repo.
## Localization
- Add/edit strings in `lib/l10n/app_en.arb`; mirror in other `app_<lang>.arb` as needed.
- Provide `@key` metadata with descriptions and placeholders.
- Dont edit `app_localizations*.dart` directly. See `docs/localization.md`.
## Releases
- Primary release flow is CIdriven. A helper exists at `scripts/release.sh`.
- Dont bump versions casually. If required, coordinate and follow `scripts/release.sh` prompts.
## When Adding Dependencies
- Justify why its needed and whether an existing dependency covers the use case.
- Prefer wellmaintained packages with strong adoption.
- Keep `pubspec.yaml` tidy; avoid overlapping functionality.
## When Touching Platform Code
- iOS: ensure entitlements, Info.plist keys, and signing remain valid.
- Android: check permissions, minSdk (23+), and manifest changes.
- Test basic run on the affected platform.
## Security & Privacy
- Credentials must use platform secure storage (`flutter_secure_storage`).
- Avoid logging sensitive information.
- Network calls should respect the configured OpenWebUI endpoint and headers.
## PR Expectations
- Keep diffs focused; include a short rationale in the PR description.
- Link related issues or TODOs when possible.
- Include screenshots or short clips for UI changes.
## If Youre Unsure
- Prefer creating a small draft PR or documenting assumptions inline with the PR description rather than pushing risky changes.
- When in doubt about ownership or expectations, open a GitHub issue first.
---
Thank you for keeping changes safe, minimal, and consistent. This helps maintain velocity and quality for the Conduit app.
## Commit & Pull Request Guidelines
- Follow Conventional Commits (`feat:`, `fix:`, `chore:`, `refactor:`) as in existing history. Keep subject lines ≤72 characters and add context in the body when behavior changes.
- Pull requests should outline the change, link issues, and list manual validation steps. Attach screenshots or recordings for UI updates.
- Rebase onto `main`, rerun codegen, and ensure CI is green before requesting review. Delete obsolete assets and localization strings in the same patch when touched.
## Localization & Configuration Notes
- Update generated delegates in `lib/l10n/` via Flutters localization toolchain (`flutter gen-l10n` from IDE or pub). Commit regenerated files with the feature change.
- Keep environment secrets outside source control; configuration surfaces and self-hosted setup notes live in `docs/`.