symphony-trello: Instructions file for Codex

Agent Operating Instructions

These instructions are repository-local and apply to Codex or any other AI agent working in this checkout. Follow them in addition to higher-priority system, developer, and user instructions.

Symphony for Trello is a senior-engineered Quarkus backend on Java 25 LTS and Maven 3 that implements the adapted Symphony-for-Trello specification in SPEC.md; work as a senior Quarkus engineer driven by that spec.

Package manager: Maven via ./mvnw (do not invoke a system Maven). The few Node-based tools use pnpm at the exact packageManager version, installed as CONTRIBUTING.md Development Setup says; do not add a package.json only to run a JavaScript CLI.

Before creating any commit that may be pushed, verify the configured author against the authenticated GitHub account even when the checkout already carries an author-verification marker. Before every push, inspect the author of every outgoing commit. Never publish generic or test identities such as Test User or example.invalid; follow the commit and push skills to correct a feature branch, and stop on the default branch unless the maintainer explicitly authorizes a history rewrite.

Every commit that reaches main is one cohesive change, on every pull request, outside contributors' included. Squash a one-change pull request; otherwise clean up its history to one commit per change and merge it with a rebase merge. Fold each review fix into the commit it fixes, keeping that commit's author, unless the fix is a cohesive change of its own, and re-check the Commit History in Main checkboxes after every push. Pull-request review checks the history; see Committing and pull requests and Outside contributor pull requests.

Before starting any task, open docs/agents/default-workflow.md and follow it.

When a user corrects a repeatable mistake or states a generally useful working preference, make the durable agent-doc update proactively in the same change; do not wait for the user to explicitly ask for persistence. If the right persistence scope is unclear, ask before finishing. Unless the user explicitly requests a one-off fix, every fix MUST address the general root cause rather than only the immediate symptom. When the original failure can be reproduced safely and within scope, verify it before and after the change to prove that the root-cause fix resolves it. Add a regression test or another durable guardrail proportionate to the failure. If direct reproduction, post-fix verification, or a guardrail is infeasible, document the specific constraint and remaining risk in the handoff. When an installed skill eval issue captures bad or missing behavior, add or update the corresponding temporary repo-local override described in Default workflow and Java style & design preferences. At the point a task makes or explains a deliberate design tradeoff, before implementing or publishing the chosen path, make the decision explicit in the code where possible and check whether Specification & ADR discipline requires an ADR. An implementation, pull-request description, checklist, review reply, or chat summary is not a substitute for a required ADR. Add or update it before the user asks. For repeated literals, scenario-table values, parallel edits that look coupled, and Java collection mutability defaults, apply the centralization and refactoring guidance in Java style & design preferences. When adding or editing tests, apply the AssertJ and test-duplication guidance in Testing, including avoiding assertion loops or assertion streams when AssertJ can express the expectation directly.

Follow the compatibility and migration rules in Compatibility discipline.