Fix AGENTS.md including Ecto references in --no-ecto projects #6581
Conversation
SteffenDE
left a comment
SteffenDE
left a comment
There was a problem hiding this comment.
I don't think we should go ahead with this as is, see comments below.
| - Fields which are set programatically, such as `user_id`, must not be listed in `cast` calls or similar for security purposes. Instead they must be explicitly set when creating the struct | ||
| - **Always** invoke `mix ecto.gen.migration migration_name_using_underscores` when generating migration files, so the correct timestamp and conventions are applied | ||
|
|
||
| ### Creating LiveView forms from changesets |
There was a problem hiding this comment.
This only moves the problem around. Now, you'd get LiveView content when you use --no-live. For the AGENTS.md, we could solve this by using .md.eex files and then checking <%= if live do %> etc., but since these files are also valid usage_rules, so we can't use eex :(
Maybe we need to split this even further, into an ecto-liveview.md and concat that conditionally? Although this refers to LiveView, the content is also valid for Phoenix forms without LiveView.
|
|
||
| - **Never** nest multiple modules in the same file as it can cause cyclic dependencies and compilation errors | ||
| - **Never** use map access syntax (`changeset[:field]`) on structs as they do not implement the Access behaviour by default. For regular structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist, `Ecto.Changeset.get_field/2` for changesets | ||
| - **Never** use map access syntax on structs as they do not implement the Access behaviour by default. For structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist |
There was a problem hiding this comment.
| - **Never** use map access syntax on structs as they do not implement the Access behaviour by default. For structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist | |
| - **Never** use map access syntax on structs (`my_struct[:field]`) as they do not implement the Access behaviour by default. For structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist |
| <.form for={@data} id="my-form"> | ||
| <.input field={@data[:field]} type="text" /> |
There was a problem hiding this comment.
I don't think this change is good, as nobody would write that, and it probably doesn't really get the point across to the LLM.
2 participants
When generating a new Phoenix project with
--no-ecto, the AGENTS.md file still contained references to Ecto (changesets, schemas, etc.). This confused AI agents working on these projects since they'd see Ecto guidelines, but the project doesn't actually use Ecto.--no-ecto.Please feel free to comment with ideas on how to better handle the
<.form for={@changeset} id="my-form">to<.form for={@data} id="my-form">change. Ideally we'd keep changeset info for Ecto projects but use generic data examples for non-Ecto Phoenix apps.