The .test manifest carries the picker rule, the list columns and the parent state a child refuses - #7681
Merged
delchev merged 1 commit intoOct 5, 2026
Conversation
…parent state a child refuses The app-test manifest described a relation as "pick any row of the target" and a list as "a header per non-major:false field", so the generic flows built samples the generated app then rejected: - a picker narrowed by `pickable:` never offered the first target row, so the record never saved (eclipse-dirigible#7663); - a list curated with `list:` was asserted to render a column the page deliberately hides - and only on the first instance that held a row, since an empty list never reaches the assertion (eclipse-dirigible#7664); - a child guarded by a `forbidWhen` over its parent's status had its REST create answered 400 by a rule nothing in the manifest mentioned (eclipse-dirigible#7667). Three keys close it, each in the manifest's own vocabulary rather than a second one: - a relation's `pickable` - `{when: [{by, op, value}], hide}`, parsed by `PickableSupport` from the same terms the generated picker evaluates; - a relation's `forbiddenTarget` - the entity's own `forbidWhen` terms that reach one hop through THAT relation, with the check's message, which is what the REST flow needs since it never sees a picker; - the entity's `list` - the `.model`'s `listOrder`, in order. All three are emitted only when authored, so an uncurated module's manifest is byte-identical. Fixes eclipse-dirigible#7663 Fixes eclipse-dirigible#7664 Fixes eclipse-dirigible#7667 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Fixes #7663
Fixes #7664
Fixes #7667
The app-test manifest described a relation as "pick any row of the target" and a list as "a header per non-
major: falsefield". The generic flows therefore built samples the generated app then rejected, and the three issues are the same gap seen from three sides:pickable:never offered the sampled row, so the record never saved and the crud flow failed on a row it could not find.list:was asserted to render a column the page deliberately hides. The failure appears on whichever instance first holds a row, not when the curation lands, because an empty list only reaches the empty-state assertion.forbidWhenover its parent's status had its REST create answered 400 by a rule nothing in the manifest mentioned. The guard is right; the flow could not satisfy it.Three keys, in the manifest's own vocabulary rather than a second one beside it:
pickable{when: [{by, op, value}], hide}, parsed byPickableSupportfrom the same terms the generated picker evaluates.opiseq/ne/present/absent; a presence test carries no value.forbiddenTargetforbidWhenterms that reach one hop through that relation, each with the check's message. This is the half the REST flow needs, since it never sees a picker.list.model'slistOrder— the curated columns, in order.byis the namewherealready uses, and a numeric literal stays a number so the runner compares it with the stored id.All three are emitted only when authored, so an uncurated module's manifest is byte-identical. Covered by
AppTestIntentGeneratorTest(one test for the curated, guarded module and one pinning that an uncurated relation carries none of them). The engine-intent suite is green: 1481 tests.Note for the SDK side: the flows have to read these. This change is the manifest half.