Convert Feature and Rule Builder Documentation to UI-First Standard - #93
Conversation
Audit and refactor feature pages in action-type/ and rule-builder/ to adopt a UI-first documentation standard. - Move internal handler names, Python evaluation details, return contracts, and bytecode notes to developer architecture reference files. - Replace manual expression syntax (@doc..., /fetch, etc.) with visual, step-by-step instructions using the Smart Value Selector. - Add visual ASCII branching and flow diagrams to logic and control actions (Check, Repeat, Switch, Stop/Error, Wait, Sub-Rule). - Remove hardcoded performance claims in favor of qualitative explanations. - Cross-link user guides to corresponding developer architecture reference pages.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 91722960de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 3. **Subject**: `"Order Confirmation: {doc.name}"` composed via Smart Value Selector. | ||
| 4. **Message**: `"Dear {doc.customer_name}, thank you for your order on {doc.posting_date}."` |
There was a problem hiding this comment.
Use Jinja syntax in notification templates
When users type the practical examples into an Email Notify action, the single-brace expressions are treated as literal text rather than template variables: Notify subjects and messages are rendered through Jinja. This causes recipients to receive {doc.name}, {doc.customer_name}, and {doc.posting_date} instead of document values; the same incorrect syntax is repeated in action-type/notify/email.md. Show {{ doc.name }}-style expressions (or the selector-generated token syntax) instead.
Useful? React with 👍 / 👎.
| - Click the **Collection** field. | ||
| - Use the **Smart Value Selector** to select a child table (e.g., `Items` or `doc.items`) or a query result (e.g., `vars.open_invoices`). | ||
| 3. **Set Item Alias**: | ||
| - Enter a variable name to represent the active row during iteration (default is `item`, accessed as `@vars.item` or `@vars.row`). |
There was a problem hiding this comment.
Document the default loop alias accurately
When an author leaves Item Alias at its default and follows this instruction to use @vars.row, that value is never bound: the loop falls back only to the item alias, while @vars.row is valid only after explicitly setting the alias to row. This makes downstream actions fail to find the current item, so the default example should name only @vars.item.
Useful? React with 👍 / 👎.
Converted all FlexiRule feature pages and Rule Builder guides into UI-first documentation focused on user goals, visual interactions, and the Smart Value Selector. Relocated low-level implementation details and return contracts to developer architecture documentation.
PR created automatically by Jules for task 11743348014279630518 started by @abdoruzaqi