# Project AGENTS Router Root `AGENTS.md` is routing + cross-domain policy only. Do not place backend/frontend implementation details here. ## Scope - Applies to repository root and cross-domain tasks. - Subdomain rules: `backend/AGENTS.md`, `apps/AGENTS.md`. - If rules conflict, use the stricter one. ## Rule Order 1. System / developer / platform safety instructions 2. Workspace runtime rules (`AGENTS.md` + `rules/*`) 3. This file (routing + project-level constraints) 4. Subdomain rules (backend/apps) ## Mandatory Routing - `backend/**` must follow `backend/AGENTS.md`. - `apps/**` must follow `apps/AGENTS.md`. - Cross-domain changes must satisfy all relevant subdomain rules. - `infra/**` follows this file plus `infra/` conventions. ## Project-Wide Constraints - Default development branch is `dev`; do not develop directly on `main`. - Never push unless explicitly requested by the user. - Keep AGENTS layered and lean: shared rules at root, domain rules in sub-AGENTS. - **No Error Swallowing**: All exceptions must propagate or be converted to typed errors. Never catch an exception, log it, and silently continue. This destroys debuggability. ## Git Safety (CRITICAL) - **NEVER execute `git checkout -- ` or any git command that modifies files without explicit user approval.** - **NEVER reset, revert, or discard uncommitted changes without user consent.** - If you need to discard changes, ask the user first and explain exactly what will be lost. - Before any destructive git operation, list the affected files and get confirmation. - This rule is non-negotiable. Violation will cause irreversible loss of user work. ## Protocol Source of Truth `docs/protocols/` is the single source of truth for protocol and data format. - Update protocol docs before changing data/API/UI contracts. - Document compatibility strategy (backward-compatible vs migration). - Keep frontend/backend implementations aligned with documented protocol. ## Database Access When viewing data in the database, use `supabase mcp` tools (`supabase_execute_sql`, `supabase_list_tables`, etc.) instead of direct queries or other methods. ## Test - test_user_email: test@example.com - test_code: 123456 - login directly, do not send verfiy code # Trellis Instructions These instructions are for AI assistants working in this project. This project is managed by Trellis. The working knowledge you need lives under `.trellis/`: - `.trellis/workflow.md` — development phases, when to create tasks, skill routing - `.trellis/spec/` — package- and layer-scoped coding guidelines (read before writing code in a given layer) - `.trellis/workspace/` — per-developer journals and session traces - `.trellis/tasks/` — active and archived tasks (PRDs, research, jsonl context) If a Trellis command is available on your platform (e.g. `/trellis:finish-work`, `/trellis:continue`), prefer it over manual steps. Not every platform exposes every command. If you're using Codex or another agent-capable tool, additional project-scoped helpers may live in: - `.agents/skills/` — reusable Trellis skills - `.codex/agents/` — optional custom subagents ## Subagents - ALWAYS wait for every spawned subagent to reach a terminal status before yielding, acting on partial results, or spawning followups. - On Codex, this means calling the `wait` tool with the subagent's thread id (requires `multi_agent_v2`). Do NOT infer completion from elapsed time. - On Claude Code / OpenCode, this means awaiting the Task/agent tool result before continuing. - NEVER cancel or re-spawn a subagent that hasn't finished. If a subagent appears stuck, raise the wait timeout (Codex default 30s, max 1h) before judging it broken. - Spawn subagents automatically when: - Parallelizable work (e.g., install + verify, npm test + typecheck, multiple tasks from plan) - Long-running or blocking tasks where a worker can run independently - Isolation for risky changes or checks Managed by Trellis. Edits outside this block are preserved; edits inside may be overwritten by a future `trellis update`.