Streamline generated AGENTS.md usage rules

[josevalim]

Prune redundant Phoenix, Ecto, Elixir, HTML, LiveView, and testing guidance. Consolidate the remaining form, stream, hook, and test rules, correct stream prepend positioning, and include Ecto.Query in generated seed files.

Update the generated rules according to the following principles:

1. Remove information that is now commonplace, such as Tailwind v4 setup.

2. Remove information covering mistakes that already produce compilation errors.

3. Remove negative “do not” guidance in accordance with current model prompting guidelines.

4. Evaluate each rule through an isolated Codex section coordinating Codex and Claude CLI runs with the prompt below:

   Evaluate whether these rules are necessary in AGENTS.md by testing both
   Codex and `claude -p`.
   
   For each rule:
   
   1. Ask a realistic code-generation question whenever possible.
   2. Do not reveal or hint at the expected answer in the question.
   3. Run both models from an empty temporary directory without repository instructions or local context.
   4. Critically inspect the generated code:
      - Remove the rule if both models follow it unaided.
      - Keep the rule if either model misses a material requirement. - Correct the rule if the models use an equally valid modern approach or expose an inaccurate detail.
   
   Treat each section as one question unless asked otherwise. If a question
   is leading or the result is ambiguous, rewrite it and rerun the test.
   
   Run every question three times through each CLI. Evaluate consistency
   across all three runs and provide results only after all runs complete.
   
   Rules to evaluate:
   
   [PASTE RULES HERE]
   

[rhcarvalho]

Manually read through most of the changes except some large chunks of removed lines. Sharing my notes before closing the tab ;)

[rhcarvalho]

Good approach to simply include the import in the scaffolding!

[rhcarvalho]

Noticed this might be one of those "do not" rules?

[josevalim]

The "do not" rules are mostly to avoid pairing "DO" with "DO NOT"s. In this case, it is a valid DO NOT.

[rhcarvalho]

Are the newer models really good about following this consistently? I would think this is an easy mistake to make with my human brain :)

[josevalim]

Yes, I prompted them two implement a guard and a function, giving only a description of the body, never the names, and it followed it all times.

[rhcarvalho]

Out of my head, not tested against a coding agent:

Suggested change

	- **Always** add unique DOM IDs to key elements (like forms, buttons, etc) when writing templates, these IDs can later be used in tests (`<.form for={@form} id="product-form">`)
	- **Always** add unique and deterministic DOM IDs to key elements (like forms, buttons, etc) when writing templates, these IDs can later be used in tests (`<.form for={@form} id="product-form">`)

or

Suggested change

	- **Always** add unique DOM IDs to key elements (like forms, buttons, etc) when writing templates, these IDs can later be used in tests (`<.form for={@form} id="product-form">`)
	- **Always** add unique and stable DOM IDs to key elements (like forms, buttons, etc) when writing templates, these IDs can later be used in tests (`<.form for={@form} id="product-form">`)

---

The importance of deterministic/stable is that form recovery depends on that, and change-tracking would unnecessarily send diffs if IDs were unique but randomly generated. Might be something for the regular docs, though.