Rules for creating the table

You are an expert in analyzing web documents to create comprehensive documentation of user interactions based on previously identified actions. Your goal is to extend the list of actions to cover all possible user interactions, without duplicating any actions.

Given a web document, and a list of previously identified actions, you must provide your output in EXACTLY 3 sections. YOUR OUTPUT MUST CONTAIN EXACTLY 3 SECTIONS, NOTHING MORE:

• Compare the provided previous action list against the document to identify new or modified actions.
• Count of all terminal nodes by type (B, L, I, O, M) that have not been previously identified
• Verification that each ID appears exactly once in the document
• Discussion of how you identified parameters
• Discussion of your categorization strategy
• Explanation of how you grouped similar functionalities
• Final count verification
• Explain your reasoning for the preparation of the table This section should contain all your reasoning and analysis steps. For each section above, start with a new line and a new paragraph with #.

Rules for creating the table:

1. ID Column:

• Each ID must appear exactly once
• NO GROUPING OF IDs (e.g., "L8-L27" is FORBIDDEN)
• IDs must match exactly as they appear in the document (B1, L1, I1, O1, M1, etc.)

2. Description Column:

• Must be concise and self-explanatory without seeing the interface
• Should clearly state what action/functionality the element provides
• Include current state/value where applicable
• Should be understandable in isolation
• Ideally, start with an action verb (Select, Enter, Search, View, etc.) BAD: "New York to London" GOOD: "Show flights from New York to London" BAD: "Enable to subscribe" GOOD: "Subscribe to the newsletter to get updates"

3. Parameters Column:

• For elements with ID starting with 'I': document all parameters
• Format: name: parameterName: type: parameterType, default="default_value", values=["value1", "value2", ...]
• Example: name: destination: type: str, default="New York", values=["New York", "London", "Paris"]
• Default value should only be included if there is an explicit default value in the document
• Values represent what this parameter can take. They should be included if there is an explicit list of possible values in the document. Let this be empty if there is no list of possible values.
• Types should be: str, number, date, boolean
• For non-input elements, leave the Parameters column empty
• Parameter names should be as descriptive as possible and understandable without context
• Parameter names should be camelCase

4. Category Column:

• Group similar actions into logical categories
• Use clear, descriptive category names
• Common categories include but are not limited to:
  • Navigation (site navigation, major sections)
  • Search & Input (core search functionality)
  • Settings & Preferences
  • User Account
  • Help & Support
  • Discovery & Exploration
  • Legal & Policy
  • Newsletter
• Each action must be assigned to exactly one category
• Categories should be consistent across similar actions
• Category names should be clear to users who can't see the page

Critical Rules:

• Every ID must have exactly one entry
• No grouping of IDs allowed (e.g., no "L10-L20")
• Button and Link elements should almost always have "None" for parameters
• Descriptions must be complete sentences that clearly describe the action
• Default values must be documented when present in the source
• Categories must be logically coherent and user-focused
• Be complete: list all actions of the document inside the table, don't miss any or use ellipsis (...)

Example of CORRECT entries: | ID | Description | Type | Parameters | Category | | B1 | Open the main navigation menu | Button | | Navigation | | I1 | Allow user to select trip type | Combobox | name: tripType: type: str, default="round-trip", values=["round-trip", "one-way", "multi-city"] | Flight Search | | O1 | Select the "round-trip" option | Option | | Flight Search | | L1 | Open the home page | Link | | Navigation |

Example of INCORRECT entries: | ID | Description | Type | Parameters | Category | ❌ | L8-L27 | Show popular destinations | Link | None | Navigation | ❌ | B1 | Main menu | Button | None | Nav | ❌ | I1 | Trip type | Combobox | type: string | Search | ❌ | ... | ... | ... | ... |

ACTION EXTENSION CRITICAL RULES:

• Remember that your objective is to extend the list of actions to cover all possible user interactions, without duplicating any actions.
• Don't try to change the previous actions too much. Of course, if necessary, you can also update previously identified actions.

Example output:

Please analyze the following web document and provide your output following these strict rules

Please analyze the following web document and provide your output following these strict rules. CRITICAL: DO NOT USE "# Step 1: Document Summary.... # Step 2: Document Analysis.... # Step 3: Action Listing..." CRITICAL: structure your output as: ..., ... and ... tags:

Your turn:

{{{previous_action_list}}} {{{document}}}