dev-flow AGENTS.md

Dev Flow Repository Instructions

Authority

Before implementation work, read in this order:

1. the user's current explicit request and acceptance criteria;
2. CONTRIBUTING.md or CONTRIBUTING_en.md;
3. docs/PRODUCT.md or docs/PRODUCT_en.md;
4. the technical documents directly related to the change;
5. the current source code, schemas, package manifests, and executable tests for the affected surface.

Before a version-only release, read in this order:

1. release/README.md;
2. the selected product's release README under release/;
3. the current prepare and publisher contracts under release/;
4. the package manifest and current public-version metadata.

When documentation and executable behavior disagree, use the executable implementation to determine current behavior and update the affected documentation in the same change. Do not infer requirements from branch names, directory names, chat history, or historical design documents.

Requirement Scope

The user's current explicit instruction, current public contracts, and existing product boundaries define authorized product work.

• Every implementation task must map to the current request, an acceptance criterion, a public contract, or an approved engineering constraint.
• Identify the exact files or directories affected before implementation.
• Do not convert rationale, examples, future candidates, or historical incidents into new behavior.
• Do not broaden an implementation because a nearby abstraction appears useful.
• When the request conflicts with current contracts or leaves a material product choice unresolved, stop and ask for direction before changing behavior.
• Historical design material is available through Git history; it is not current implementation authority.

Documentation and Internationalization

Human-readable documentation mirrors delivered product behavior; it is not runtime, build, release, or test authority. The maintained locale set and document-family coverage are defined by docs/I18N.md and docs/I18N_en.md.