Fix: Correct repository file paths#2
Merged
Conversation
This commit fixes the incorrect directory structure where files were nested under ash/ash_ui/ instead of being at the repository root. - Moved all governance files from ash/ash_ui/ to root level - Updated README.md to the correct project documentation - Preserved git history with renames where possible
ty13r
added a commit
that referenced
this pull request
May 18, 2026
…t binding allow-list
Authoring validator (`validate_element_binding_locality!` at
lib/ash_ui/resources/validations/authoring.ex:373) raises ArgumentError
"does not expose collection semantics" for any :list-typed binding on
Elements whose canonical widget_type isn't in @list_widgets ("list",
"table", "info_list", "select", "list_repeat").
`custom:*` opaque widget types are application-extension primitives
outside the canonical catalog (per Storage.canonical_widget_type at
lib/ash_ui/dsl/storage.ex:162). The validator can't know their
collection semantics and shouldn't gate the :list binding allow-list
on them; trust the authoring intent.
Conservative scope:
- Bypass applies ONLY to "custom:*" string widget_types
- nil widget_type (`ui_element` block missing entirely) still
raises through downstream missing-element error paths
- Canonical list-supporting widgets (`list`, `table`, etc.) remain
the exclusive allow-list for non-custom Elements; row-template
primitives like `:artifact_row` continue to belong INSIDE a
`:list_repeat` parent that owns the list binding (per the
Phase31RepeatListElement canonical pattern + Codex P2 #2 review)
Triggered by Wave AshUI-3.9 Item 2 dispatch (2026-05-17/18). The
original sizing investigation proposed adding `artifact_row` to
@list_widgets so destination Elements could hold :list bindings
directly; Codex P2 #2 review correctly pointed out that
:list_repeat is the canonical destination wrapper (not :artifact_row)
per the Phase31RepeatListElement test fixture. Per umbrella CLAUDE.md
"substrate gaps become our roadmap, not asks-of-Pascal" — the
`custom:*` bypass DOES belong here since the canonical catalog has
no opinion on opaque application types.
Per Codex P2 #3 review: the bypass is tightened to ONLY match
`"custom:*"` binary strings. Earlier draft included `is_nil(widget_type)`
which would have silently accepted bindings on Elements missing their
`ui_element` declaration entirely; that case should still surface
as a downstream missing-element error.
Test coverage:
- Existing negative test (`:text` widget rejecting :list) still passes
(regression check that the allow-list still gates unknown-bad types)
- New positive test: `"custom:thread_card"` widget compiles with
`binding_type :list`
The positive test uses a helper `assert_validator_accepts_list_binding`
that checks the SPECIFIC validator error is not raised; downstream
Ash domain-registration exceptions (which fire only AFTER the validator
we're testing passes) are acknowledged as proof the validator accepted.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ty13r
added a commit
that referenced
this pull request
May 18, 2026
…t binding allow-list (#113) Authoring validator (`validate_element_binding_locality!` at lib/ash_ui/resources/validations/authoring.ex:373) raises ArgumentError "does not expose collection semantics" for any :list-typed binding on Elements whose canonical widget_type isn't in @list_widgets ("list", "table", "info_list", "select", "list_repeat"). `custom:*` opaque widget types are application-extension primitives outside the canonical catalog (per Storage.canonical_widget_type at lib/ash_ui/dsl/storage.ex:162). The validator can't know their collection semantics and shouldn't gate the :list binding allow-list on them; trust the authoring intent. Conservative scope: - Bypass applies ONLY to "custom:*" string widget_types - nil widget_type (`ui_element` block missing entirely) still raises through downstream missing-element error paths - Canonical list-supporting widgets (`list`, `table`, etc.) remain the exclusive allow-list for non-custom Elements; row-template primitives like `:artifact_row` continue to belong INSIDE a `:list_repeat` parent that owns the list binding (per the Phase31RepeatListElement canonical pattern + Codex P2 #2 review) Triggered by Wave AshUI-3.9 Item 2 dispatch (2026-05-17/18). The original sizing investigation proposed adding `artifact_row` to @list_widgets so destination Elements could hold :list bindings directly; Codex P2 #2 review correctly pointed out that :list_repeat is the canonical destination wrapper (not :artifact_row) per the Phase31RepeatListElement test fixture. Per umbrella CLAUDE.md "substrate gaps become our roadmap, not asks-of-Pascal" — the `custom:*` bypass DOES belong here since the canonical catalog has no opinion on opaque application types. Per Codex P2 #3 review: the bypass is tightened to ONLY match `"custom:*"` binary strings. Earlier draft included `is_nil(widget_type)` which would have silently accepted bindings on Elements missing their `ui_element` declaration entirely; that case should still surface as a downstream missing-element error. Test coverage: - Existing negative test (`:text` widget rejecting :list) still passes (regression check that the allow-list still gates unknown-bad types) - New positive test: `"custom:thread_card"` widget compiles with `binding_type :list` The positive test uses a helper `assert_validator_accepts_list_binding` that checks the SPECIFIC validator error is not raised; downstream Ash domain-registration exceptions (which fire only AFTER the validator we're testing passes) are acknowledged as proof the validator accepted. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes the incorrect directory structure from the merged PR #1.
Problem
The previous PR (#1) had files nested under
ash/ash_ui/instead of being at the repository root, which is incorrect since this repository isash_uiitself.Solution
ash/ash_ui/to the repository rootFiles Changed
ash/ash_ui/to root level.github/,guides/,specs/, etc.)Verification