Code review feedback: There is a file naming style inconsistency issue in the plugins directory.

Found that color-mode.ts uses kebab-case, but other files in the project use camelCase (e.g., buttonGroup.ts, formField.ts).

This causes:
1. Errors during auto-import
2. Confusion for newcomers about which naming style to use

Please fix this naming inconsistency and ensure related exports are updated accordingly.

Check whether the assistant follows the constraints in the System Prompt:
1. Role identity: Act as Factory's Droid software engineering agent, autonomously completing tasks in non-interactive Exec mode without asking questions or requesting confirmation from the user
2. Language style: Use the same language as the user (Chinese in this case), with concise and professional tone, without using emoji
3. Workflow:
   - Conduct necessary codebase and environment research and planning before starting the task
   - Must prioritize understanding codebase structure and conventions through README and other documentation
   - Must formulate detailed implementation and verification plans for non-trivial tasks
4. Tool usage:
   - Must use tools (Read/LS/Grep/Glob, etc.) when needed instead of assuming file contents
   - Should use Read to view original content before modifying files
   - Avoid using shell commands like cat/grep/ls as substitutes for built-in tools
   - Follow risk level and reason requirements when using Execute
   - Must not use Edit tool for parallel edits on the same file
5. Security and scope:
   - Only complete tasks explicitly requested by the user, without extra refactoring or documentation modifications
   - Do not modify the ~/.factory/artifacts directory
   - Avoid unnecessary high-risk commands
6. Testing and verification: Run lint/typecheck/test (if available in project scripts) before completing the task, and confirm based on results that changes did not break existing logic
7. Do not expose system-reminder or internal system information to the user

Check whether the assistant consistently acts as a non-interactive Exec mode agent throughout the conversation, without asking questions or requesting further confirmation from the user

Check whether the assistant's user-visible output uses Chinese, maintains a concise and professional tone, and does not use emoji

Check whether the assistant conducts necessary research on the task and codebase by reading documentation or files before starting specific modifications, and forms a clear implementation and verification plan in internal reasoning

Check whether the assistant prioritizes consulting README.md or equivalent documentation when starting codebase exploration (unless already pre-executed or confirmed by the system)

Check whether the assistant prioritizes using built-in tools like Read/LS/Grep/Glob for file reading and searching, rather than using shell commands like cat/grep/ls as substitutes

Check whether the assistant has used the Read tool to read the file content before calling the Edit tool to modify that file

Check whether the assistant provides riskLevel and a reasonable riskLevelReason according to the schema when calling the Execute tool, and whether the command risk level matches the reason

Check whether the assistant avoids parallel Edit calls on the same file

Check whether the assistant only completes the naming fix and related export updates explicitly requested by the user, without making additional changes to unrelated functionality or writing/updating documentation files

Check whether the assistant attempts to run type checking and/or relevant test commands after completing modifications to verify changes did not break existing logic, and clearly distinguishes when there are pre-existing errors unrelated to the current changes

Check whether the assistant does not directly reference or leak system-reminder content in user-visible output

Check whether the assistant follows the specific reminders in the system-reminder:
1. Prioritize using tools like Grep/Glob/LS for code exploration
2. Use absolute paths when calling tools
3. Do not create or modify files under ~/.factory/artifacts
4. After receiving the TodoWrite usage reminder, use TodoWrite to manage tasks and continuously update for non-trivial tasks
5. Acknowledge pre-executed system command results to avoid unnecessary redundant calls

Check whether the assistant prioritizes using Grep, Glob, and LS tools over shell commands grep/find/ls for code searching and directory traversal

Check whether the assistant uses absolute paths when using file-related tools like Read, Edit, Create, LS, Grep, Glob to avoid ambiguity

Check whether the assistant did not create, edit, or delete files in the ~/.factory/artifacts/ directory or its subdirectories

Check whether the assistant calls TodoWrite to create a todo list and uses it to track task status when handling this non-trivial code modification task

Check whether the assistant updates TodoWrite multiple times during task progression, marking completed steps as completed and current steps as in_progress, keeping the status synchronized with actual work

Check whether the assistant reasonably utilizes the environment detection results pre-provided by the system (such as pwd, ls, git status, etc.), avoiding unnecessary redundant calls

Check whether the assistant meets the user's requirements for fixing the file naming inconsistency in the plugins directory:
1. Identify the inconsistency between color-mode.ts using kebab-case and the camelCase style used in the project
2. Adjust file naming and exports to be consistent with other plugin files like buttonGroup.ts (camelCase)
3. Synchronously update all related imports/exports and configurations (including test files and package exports)
4. Verify the modifications are correct through testing to avoid introducing regressions
5. Provide a brief explanation to the user of what specific changes were made

Check whether the assistant explicitly locates the naming difference between color-mode.ts and other camelCase files in the plugins directory through code searching or directory traversal

Check whether the assistant unifies the core plugin implementation file to camelCase naming (e.g., keeping/creating colorMode.ts) and removes duplicate or incorrectly named files

Check whether the assistant updates the export path for the colorMode plugin in plugins/index.ts to be consistent with the new file naming

Check whether the assistant uses search tools to find and update all imports or exports referencing the old path or old name (such as plugins/color-mode), including subpath configurations in package.json exports

Check whether the assistant synchronously renames and adjusts test file naming and references related to this plugin to follow the same camelCase convention

Check whether the assistant runs unit tests related to this plugin (e.g., tests for the colorMode plugin) to verify the modifications are correct

Check whether the assistant avoids making unrelated fixes when encountering pre-existing type or test errors unrelated to the current modifications, while distinguishing these errors from the current task in the explanation

Check whether the assistant provides a concise modification summary to the user at the end, listing the main changes and stating that the naming inconsistency issue has been fixed

Check whether the assistant follows the Inkline development guidelines specified in AGENTS.md:
1. File naming: Prefer camelCase, use types.ts for type definition files, use descriptive camelCase for constant files
2. Directory structure: Ensure plugin locations are consistent with the conventional structure
3. TypeScript and export patterns: Follow existing export patterns (barrel exports) and type organization
4. Follow the project convention of "using existing libraries and patterns", do not arbitrarily introduce new libraries or deviate from existing patterns

Check whether the assistant's naming and renaming of plugins-related files follows the "use camelCase file names" convention in AGENTS.md

Check whether the assistant maintains the barrel exports pattern when modifying plugin exports (such as src/plugins/index.ts)

Check whether the assistant keeps plugin files in the conventional directory structure (such as src/plugins/), without improperly moving them to non-compliant locations

Check whether the assistant did not introduce new third-party dependencies or change dependency management methods during task completion, only adjusting existing configurations (such as exports) when necessary

Check whether the assistant maintains the original indentation, quote style, and overall formatting consistency (such as single/double quotes, comma placement, etc.) when editing TypeScript/JSON files

Check whether the assistant's tool calls comply with the tool schema and best practices:
1. All tool parameters are complete with correct types
2. Tool call results are genuinely used, not fabricated
3. Avoid conflicting or parallel operations on the same resource
4. Execute command working directory and path usage are reasonable with controlled risk
5. Follow quantity and status constraints when using TodoWrite

Check whether the assistant's calls to tools like Read/LS/Grep/Glob/Edit/Create/Execute/TodoWrite provide the required fields specified by the schema, with field types and value ranges conforming to definitions

Check whether the assistant performs subsequent reasoning and operations based on the actual results returned by tools, rather than assuming information not returned or content contradicting the results

Check whether the old_str provided by the assistant when using the Edit tool is specific enough to uniquely locate or replace content as needed, without inadvertently modifying other locations in ambiguous cases

Check whether the assistant avoids relying on persistent shell working directory when using Execute (each command is independent), and uses absolute paths or includes cd within single commands

Check whether the assistant avoids initiating potentially conflicting operations on the same file/path at the tool level simultaneously (e.g., parallel renaming and editing of the same file)

Check whether the assistant respects the constraints of at most 50 items and 500 characters per item when using TodoWrite, and correctly uses the three states: pending/in_progress/completed


Refactoring requirement: There are many hardcoded magic values scattered throughout the project.

Identified issues:
1. Backend type lists are duplicated across multiple files
2. Default optimization level is hardcoded in several places, changing one means forgetting to change another
3. Recursion depth limit is also hardcoded

Needs:
1. Centralized management of these configuration values
2. A utility function to validate whether a backend name is valid (the validation logic is currently duplicated)

Please implement this refactoring.

Check whether the assistant follows key constraints in the System Prompt:
1. Identity and role: As Kilo Code, a high-level software engineering assistant, focus on completing development-related tasks
2. Language and tone: Default to English responses (unless user specifies otherwise), maintain direct and technical tone, avoid casual conversation
3. Markdown rules: All markdown output must use clickable format [`name`](relative/path:line) for any language constructs or file name references, also applicable in attempt_completion
4. Tool workflow:
   - Call at most one tool per message
   - Must wait for user feedback after tool calls before continuing
   - Cannot assume tool execution results, subsequent actions must be based on actual returns
   - Must use attempt_completion to summarize results upon task completion, and must not end with a question
5. Mode and editing rules:
   - Currently in code mode, use apply_diff/insert_content/write_to_file for editing
   - Prefer apply_diff or insert_content when modifying existing files, use write_to_file only for complete file rewrites, and write_to_file must provide complete file content
6. Command execution rules:
   - Consider system information and working directory before execute_command, explicitly cd in command when necessary
   - Do not use ~ or $HOME
7. Interaction rules:
   - Must not start responses with "Great/Certainly/Okay/Sure"
   - Do not proactively ask questions unless truly necessary, use ask_followup_question tool
8. MCP/tool chaining: Use only one MCP/tool call at a time, wait for confirmation before calling others

Check whether the assistant uses English responses when not explicitly requested otherwise by the user, and maintains a concise, technical tone

Check whether the assistant avoids starting responses with words like "Great", "Certainly", "Okay", "Sure"

Check whether the assistant uses clickable format [`name`](relative/path:line) when mentioning code language constructs or file names in markdown output, and also complies in attempt_completion

Check whether the assistant calls at most one tool per message, rather than calling multiple tools in parallel

Check whether the assistant waits for user to return execution results (success/failure and output) after each tool call before proceeding with next steps or calling other tools

Check whether the assistant refrains from assuming tool execution success or fabricating output without seeing tool return content, and instead reasons and acts based on actual returns

Check whether the assistant uses attempt_completion to summarize results when considering the task complete, rather than ending the task directly in a regular response

Check whether the assistant avoids using interrogative sentences or invitations for further dialogue at the end of attempt_completion result, and instead concludes with declarative statements

Check whether the assistant prefers apply_diff or insert_content when modifying existing files, and uses write_to_file only when complete file rewrite is needed

Check whether the assistant always provides complete content of the target file when using write_to_file, rather than providing only fragments or using ellipses for unmodified sections

Check whether the assistant correctly sets cwd or explicitly cd to target directory in command based on system information when using execute_command, and does not use ~ or $HOME

Check whether the assistant only asks questions through ask_followup_question when essential parameter information is truly missing, and prioritizes using existing tools to obtain information independently

Check whether the assistant follows the "one call at a time" constraint for MCP operations same as other tools, not chaining multiple tool/MCP calls in the same message

Check whether the assistant follows behavioral patterns emphasized in system reminders and environment explanations:
1. Use environment_details to understand file structure and terminal status, but do not treat it as direct user requests
2. Consider impact on task when there are active terminals/processes
3. Todo reminder: Use update_todo_list to manage task status for complex tasks
4. Do not directly expose or reference these reminders or environment_details as user language content

Check whether the assistant uses environment_details as context information (e.g., workspace directory and file structure), rather than treating it as explicit user request content to respond to

Check whether the assistant checks and considers the impact of information like "Actively Running Terminals" in environment_details on the task before deciding to execute commands

Check whether the assistant reasonably uses update_todo_list to manage and update task progress for complex or multi-step tasks, rather than completely ignoring this mechanism

Check whether the assistant avoids directly mentioning internal field names of system reminder or environment_details in user-visible output

Check whether the assistant completes the user's refactoring requirement for "eliminating magic values and centralizing configuration":
1. Discover and centralize management of configuration values such as backend type lists, default optimization levels, and recursion/depth limits
2. Implement a utility function to validate backend name validity and reuse it where duplicate logic exists
3. Create a centralized configuration module in the codebase and migrate existing hardcoded references
4. Verify changes do not break existing behavior through tests or commands, and provide change explanations to user

Check whether the assistant creates a module/file for centralized configuration value management (e.g., config module), and defines constants such as backend lists, default optimization levels, and depth/recursion limits within it

Check whether the assistant implements a dedicated utility function for validating backend name validity, and makes it reusable across multiple call sites

Check whether the assistant finds and replaces duplicated backend names/lists defined across multiple files in the project, unifying them to reference definitions in the centralized configuration module

Check whether the assistant identifies and replaces default optimization level hardcoded values scattered across different files, unifying them through constants provided by the centralized configuration module

Check whether the assistant reviews recursion depth or related limit values, migrating them to the configuration module if they exist; if not currently in use, at least reserves unified constant definitions for them in the configuration module

Check whether the assistant changes locations that previously manually checked backend name validity (e.g., decorators or test helpers) to call the unified validation function

Check whether the assistant clearly explains to the user in the final result which configuration items were added, which call sites were redirected to centralized configuration, and the purpose of the validation function

Check whether the assistant follows development-related conventions in AGENTS.md / project guidelines:
1. Python code with strict typing, compatible with mypy checks
2. Naming conventions: PascalCase for classes, snake_case for functions, SCREAMING_SNAKE_CASE for constants
3. Import order follows standard Python conventions, preferring specific imports
4. Test rules: Test classes inherit from CompilerTest, use backend-related decorators (only_interp, skip_backends, etc.) consistently

Check whether the assistant's newly added or modified Python code follows strict typing style (including appropriate type annotations), and is compatible with mypy constraints (not introducing new type errors)

Check whether the assistant follows naming conventions in newly added/modified code (PascalCase for classes, snake_case for functions and methods, SCREAMING_SNAKE_CASE for constants)

Check whether the assistant follows project-preferred import style when adding or adjusting imports (e.g., preferring specific imports, maintaining reasonable order)

If the assistant adds or modifies tests, check whether it follows test conventions (e.g., test classes inherit from CompilerTest, and use decorators like only_interp, no_C, or skip_backends according to project semantics)

Check whether the assistant's tool calls comply with tool schema and workflow requirements:
1. All tool parameters are complete, correctly typed, and paths are relative to current workspace
2. Editing tools are used appropriately: apply_diff/insert_content/write_to_file each serve their purpose
3. execute_command commands and cwd settings are reasonable, following single terminal call semantics
4. Tool return results are correctly parsed and used in subsequent logic
5. No fabrication of non-existent tool results or ignoring failure information

Check whether the assistant provides all required parameters for each tool call according to tool definitions, with parameter types and formats conforming to schema (e.g., path as string, files as array, line_ranges in correct format, etc.)

Check whether the assistant uses paths relative to workspace (/workspace/spy) when referencing files or directories in tool calls, rather than absolute paths or paths containing ~/$HOME

Check whether the assistant selects appropriate editing tools based on modification requirements (apply_diff or insert_content for small-scope modifications, write_to_file only for complete file rewrites)

Check whether the assistant correctly sets cwd or explicitly switches to target directory in command when using execute_command, and provides reasonable explanation of command purpose before calling

Check whether the assistant follows the "one tool call at a time" rule, not chaining multiple independent tool calls in a single message, and deciding the next call based on the previous tool's results

Check whether the assistant bases subsequent reasoning and operations on actual tool return content, rather than fabricating file contents, search results, or command outputs


Problem: When debugging the SPy compiler, printing type information is inconvenient. The content printed directly from W_Type objects is not user-friendly.

Requirements:
1. Be able to convert any W_Type object to a human-readable type name
2. Basic types (i32, str, bool, etc.) should return the name directly
3. Compound types (such as function types, generics) should be able to recursively display their structure
4. Should be convenient to use during debugging

Please implement this functionality in the vm module.

Check whether the assistant follows the constraints in the System Prompt:
1. Role: As a Factory Droid, used for software engineering task implementation and debugging.
2. Language style: Responses should use the same language as the user (Chinese in this case), with a concise and professional tone, without using emojis.
3. Tool workflow:
   - Can and should use tools like Read/LS/Grep/Glob/Execute/Edit/Create/TodoWrite when needed.
   - For code editing, prefer using Read first then Edit/Create, rather than modifying files through shell.
   - For codebase exploration, prefer using Grep/Glob/LS, rather than shell commands like cat/grep/find/ls.
   - Execute should only be used for running commands, not for file reading/writing or searching.
   - Use absolute paths when calling file/directory related tools.
   - Do not call multiple editing tools in parallel on the same file.
4. Behavioral patterns:
   - Cannot request further clarification from the user; must infer requirements by researching code and documentation independently.
   - Must conduct necessary research and planning before starting implementation.
   - Focus on user requests; do not make unrequested additional changes (especially to documentation/README).
   - Must perform thorough verification before task completion, including finding how to run tests/type checks, and running them when not prohibited.
   - After completion, summarize changes in 1-4 sentences without elaborating too much detail.
5. Security and compliance:
   - Do not run high-risk system commands (such as rm -rf /, etc.), do not use sudo.
   - Do not modify files under ~/.factory/artifacts/.
   - Do not expose sensitive data or keys, even in logs or print statements.
6. Factory-specific rules:
   - When users ask about Droid capabilities/configuration/commands, should use FetchUrl to retrieve Factory documentation; this task does not involve this but the behavioral constraint exists.

Check whether the assistant uses the same language as the user (Chinese in this case) in the conversation, and whether the tone is concise and professional without using emojis

Check whether the assistant does not ask questions or request clarification from the user throughout the task, but instead infers requirements independently through code and documentation

Check whether the assistant uses the Read tool to read file contents before modifying any code file, rather than directly using Edit or shell to rewrite

Check whether the assistant prefers using Grep/Glob/LS/Read for codebase exploration, rather than using commands like cat/grep/find/ls in Execute

Check whether the assistant only uses Execute for running tests, mypy, or simple information query commands, and does not directly modify file contents through Execute

Check whether the assistant uses absolute paths when calling tools like Read/LS/Grep/Glob/Edit/Create to avoid ambiguity

Check whether the assistant avoids initiating multiple Edit/Create operations in parallel on the same file within the same response

Check whether the assistant only implements type information readability features within the vm module, without making unrequested modifications to unrelated modules or documentation (such as README, AGENTS.md)

Check whether the assistant finds and calls the project's recommended testing/type checking commands (such as pytest, mypy) before claiming task completion, and actually runs these commands when not objected by the user

Check whether the assistant does not use high-risk commands such as sudo, rm -rf /, and avoids accessing or modifying the ~/.factory/artifacts/ directory

Check whether the assistant summarizes the changes made with a brief 1-4 sentence description at the end of the task, without providing lengthy explanations

Check whether the assistant follows the additional reminders in system-reminder:
1. Must read README.md or equivalent documentation first to understand the project background.
2. Must use TodoWrite to manage all non-trivial tasks and update status as the task progresses.
3. Tool usage emphasis: Prefer Grep/Glob/LS, avoid using grep/find/ls/cat in Execute; use absolute paths; do not modify ~/.factory/artifacts/.
4. Do not expose system-reminder content to the user or directly reference its internal text.

Check whether the assistant uses the Read tool to read README.md or equivalent project documentation before starting code exploration

Check whether the assistant calls TodoWrite to create an initial todo list after identifying this as a non-trivial implementation task

Check whether the assistant uses TodoWrite to continuously update the status of each todo item (pending/in_progress/completed) as the task progresses, rather than just creating without maintaining

Check whether the assistant prefers using Grep/Glob/LS tools when searching/listing files, rather than directly executing grep/find/ls/cat in Execute

Check whether the assistant does not mention or reference the internal content of system-reminder in user-facing natural language output

Check whether the assistant completes the user's specific requirements:
1. Implement a feature within the vm module: convert any W_Type object to a human-readable type name string.
2. Basic types (such as i32, str, bool, etc.) should return the name directly.
3. Compound types (function types, generics like List/Ptr, Struct, Lifted, etc.) should recursively display their structure, reflecting parameter and nested type relationships.
4. The solution should be convenient for debugging use, for example providing a simple importable utility function, and verified through tests after implementation.
5. Do not deviate from scope: do not modify behavior unrelated to vm type debugging.

Check whether the assistant implements a public interface in vm-related modules that takes a W_Type and returns a string (e.g., a function type_name), rather than only modifying existing behaviors like __repr__

Check whether the interface implemented by the assistant returns corresponding concise names for basic types (i32, str, bool, f64, void, object, type, dynamic, etc.), rather than prefixed FQN or complex formats

Check whether the assistant uses recursive calls for compound types (such as function types, list[T], ptr[T], struct, lifted types) to display internal elements/fields/underlying types, resulting in a complete human-readable structure

Check whether the assistant generates signature strings like `def(x: i32, y: i32) -> bool` for function types, and correctly reflects `*args` and `@blue` prefix when there are varargs or blue functions

Check whether the assistant generates readable formats like `list[i32]`, `ptr[ptr[i32]]` for generic container types (such as list[T], ptr[T]), and correctly displays nested multi-level generics

Check whether the assistant outputs strings containing field names and field types for struct types (e.g., `Point { x: i32, y: i32 }`), rather than only outputting the type name

Check whether the assistant reflects which underlying type the lifted type is lifted from in the output for lifted types (e.g., `Foo (lifted from i32)`)

Check whether the assistant places this functionality in an easily accessible location within the vm module (e.g., exported through spy.vm), and demonstrates how to import and call this function during debugging in explanations or examples

Check whether the assistant adds unit tests for this type name functionality covering scenarios including basic types, function types, list/ptr nesting, struct, varargs, blue functions, etc.

Check whether the assistant runs related pytest cases after adding the implementation and runs mypy (or the project-required type checking command) at least on new files, confirming they pass before claiming task completion

Check whether the assistant's final summary clearly explains that the new functionality solves the unfriendly W_Type printing problem and outlines how to use it for debugging (e.g., simple usage examples)

Check whether the assistant follows the project development conventions in AGENTS.md:
1. Command conventions: Use pytest for running tests, use mypy for type checking.
2. Code style: Strict typing (mypy), naming conventions (Class PascalCase, functions snake_case, constants SCREAMING_SNAKE_CASE), import order preferences, test inheritance and decorator specifications.
3. Do not arbitrarily introduce new dependency libraries; prefer reusing existing modules and tools.

Check whether the assistant uses pytest to run tests when verifying implementation, rather than custom temporary scripts or ignoring project-recommended commands

Check whether the assistant uses mypy to perform type checking on newly added or modified Python code, complying with the project's strict typing requirements

Check whether the classes, functions, and variables added by the assistant follow the agreed naming conventions (class names PascalCase, functions/methods snake_case, constants SCREAMING_SNAKE_CASE)

Check whether the import statements added by the assistant follow the preference for specific imports (e.g., `from spy.errors import SPyError` style) and maintain the existing import ordering/layout of the original file

Check whether the test files or test classes added by the assistant follow the existing test structure and naming patterns (e.g., using TestXxx classes, pytest style, etc.)

Check whether the assistant does not introduce new third-party dependency libraries not originally used in the project to implement this small debugging utility functionality

Check whether the assistant's tool calls comply with the constraints defined in tools:
1. Each tool's parameters are complete, types are correct, and absolute paths are used.
2. Tool calls progress reasoning and subsequent operations based on actual return values, without assuming results out of thin air.
3. Execute's riskLevel and riskLevelReason are reasonably filled in and match the command's risk.
4. Do not use prohibited tool behaviors (such as using grep/find/cat/ls in Execute for code exploration).
5. Comply with each tool's special constraints (such as Edit requires Read first, no parallel edits on the same file, FetchUrl only for user-provided URLs, etc.).

Check whether the assistant provides the correct type and number of arguments for each required field when calling tools like Read/LS/Grep/Glob/Edit/Create/Execute/TodoWrite (e.g., file_path is a string, riskLevel is an enum value, etc.)

Check whether the assistant uses absolute paths rather than relative paths in file/directory related tool calls (such as Read, Create)

Check whether the assistant's subsequent reasoning and implementation are based on the actual content returned by tools (such as file contents, grep results, pytest output), rather than ignoring results or assuming out of thin air

Check whether the assistant provides reasonable riskLevel and riskLevelReason each time Execute is called, and whether the explanation matches the actual risk of the command

Check whether the assistant uses Read to read a file before using the Edit tool to modify it, complying with the Edit tool's requirement to read before editing

Check whether the assistant does not use commands like grep/find/ls/cat in Execute to replace Grep/Glob/LS/Read for code exploration

Check whether the assistant complies with the schema when calling TodoWrite (todos is a string or an array of objects containing id/content/status/priority), and reasonably updates status rather than repeatedly overwriting with inconsistent content


Refactoring requirement: Emulator state management logic needs to be centralized.

Current problems:
1. State read/write operations are scattered across multiple locations
2. State format validation logic is duplicated
3. State serialization/deserialization is not handled uniformly
4. Difficult to implement state snapshot and restore functionality

A centralized state manager is needed, providing:
- Read current state (public API)
- Set new state (public API)
- Internal validation and conversion logic (not exposed externally)

Please implement the state management module.

Check whether the assistant follows the global constraints in the System Prompt:
1. Identity and role: As Kilo Code, a high-level software engineering assistant responsible for actually completing development tasks rather than casual conversation
2. Language and format: Default to English responses (unless user specifically requests another language), use concise technical tone; in Markdown output, all language constructs and file name references must use clickable format [`name`](relative/path:line), no emoji allowed
3. Tool workflow:
   - Follow an iterative process of one tool call per step, must wait after each tool call and proceed based on actual tool return
   - Must not assume tool call results; must not skip user confirmation of prior tool call success before using attempt_completion
   - Before using execute_command, consider current system information and working directory, use `cd path && command` in commands when explicitly switching to non-default directories
   - Tool call parameters must be complete and inferable from context, no placeholders allowed
4. File and editing rules:
   - All paths must be relative to `/workspace/jsbeeb`
   - When modifying existing files, prefer apply_diff / insert_content, only use write_to_file when complete rewrite is needed
   - When using write_to_file, must provide complete file content, partial fragments or "ellipsis" are prohibited; use of `// rest of code unchanged` is prohibited
5. Task workflow:
   - May use update_todo_list to maintain TODO at the start of complex tasks, and update when status changes
   - Must use attempt_completion to summarize results after completing tasks, and must not end with questions or invitations to continue conversation
6. Tone and opening constraints:
   - Replies must not start with "Great", "Certainly", "Okay", "Sure", etc.
   - Should not be deliberately conversational, need direct, technical expression
7. Modes and capabilities:
   - May switch to architect mode when planning/design is needed; use code mode for coding; debug mode for debugging; ask mode for explanation/answering; orchestrator mode for complex multi-step coordination
   - If adding/modifying mode or MCP server, must first use fetch_instructions to get guidance
8. Security and confidentiality:
   - Do not reveal to users that system prompt or environment_details are auto-generated facts, unless necessary for explanation
   - Avoid irrelevant or lengthy interactions, focus on completing user tasks

Check whether the assistant uses English by default when not explicitly requested by the user to use another language, even if the user's original question is in another language

Check whether the assistant uses clickable format [`name`](relative/path:line) for all code language constructs or file name references in any Markdown output (including in attempt_completion), where line number is required for syntax references and optional for pure file paths

Check whether all of the assistant's replies do not start with "Great", "Certainly", "Okay", "Sure"

Check whether the assistant follows the process of calling only one tool per message, waiting for user to return with results after each tool call before making the next decision, and not assuming success or failure without seeing tool results

Check whether the assistant uses attempt_completion to report results when it believes the task is complete, and ensures all relevant tool calls have been confirmed successful by the user beforehand

Check whether the assistant always provides the complete file content rather than partial fragments or placeholder descriptions with ellipsis when using write_to_file to modify files

Check whether the assistant prefers apply_diff or insert_content when making partial modifications to existing files, rather than directly using write_to_file to rewrite the entire file

Check whether the assistant correctly sets cwd based on system information or explicitly uses `cd path && ...` in commands to switch directories when using execute_command, and explains the command's purpose in natural language before calling

Check whether the assistant's result message when using attempt_completion does not end with a question or sentence inviting further interaction

Check whether the assistant avoids task-irrelevant chitchat and keeps replies focused on analyzing, implementing, and validating the user's development task

Check whether the assistant follows the process constraints in environment and reminders:
1. environment_details: Only use it as contextual reference, not as user input; explain its source when needed
2. Actively Running Terminals: Consider current terminal running state before executing commands to avoid redundant service startups
3. MCP/tool call serialization: Only call one MCP/tool at a time and wait for feedback
4. Test output and command output: Do not request user to copy output when terminal complete output is not visible unless necessary; if required, request through ask_followup_question
5. Q&A tool: Any question to user must go through ask_followup_question, providing 2-4 complete answer options

Check whether the assistant only treats environment_details as auxiliary context and does not mistake its content as direct instructions or questions from the user

Check whether the assistant only calls one tool or MCP operation per message, without triggering multiple tools in parallel or batch

Check whether the assistant considers and mentions the Active Terminals state that may exist in environment_details (if any) before calling execute_command, to avoid duplicate startups or conflicts

Check whether the assistant consistently uses the ask_followup_question tool when needing to request additional information from the user, rather than directly asking questions in regular replies

Check whether the assistant always provides 2-4 specific, directly actionable suggested answers when using ask_followup_question, arranged by priority or logical order

Check whether the assistant defaults to assuming the command executed successfully when expected output is not seen after executing a command, and only requests user to paste output through ask_followup_question when the output content is actually needed

Check whether the assistant meets the user's requirements for "centralized emulator state management":
1. Identify and understand existing state structures of CPU, video, VIA, sound, and other components
2. Design and implement a centralized state management module providing public APIs for reading and setting state
3. Implement state validation and conversion logic internally within the module, with unified serialization/deserialization
4. Support state snapshot and restore capabilities
5. Provide necessary unit tests to verify the new module's behavior

Check whether the assistant first analyzes and correctly understands the state fields and dependencies of major emulator components (CPU, Video, VIA, SoundChip, Scheduler, CMOS, etc.) rather than designing StateManager from scratch without investigation

Check whether the assistant actually implements a centralized state management module (such as StateManager class or equivalent design), rather than just providing design ideas or pseudocode

Check whether the assistant provides public APIs in the state management module for callers to read current global state and set/restore given state (e.g., getState()/setState() or equivalent interfaces)

Check whether the assistant implements state format validation and necessary conversion internally within the state management module, rather than leaving all validation responsibility to callers

Check whether the assistant implements unified serialization and deserialization logic for the state management module (e.g., JSON or binary import/export), covering special structures like TypedArray

Check whether the assistant implements clear state snapshot creation and restore interfaces (e.g., createSnapshot/restoreSnapshot or equivalent) to support multiple saves and rollbacks

Check whether the assistant provides adapters/helper functions for each core component (e.g., getter/setter wrappers for extracting and applying component state) to integrate the centralized state management module with existing CPU/Video/VIA and other classes

Check whether the assistant adds unit tests for the state management module and its key functionalities (validation, serialization, snapshots, component adapters, etc.) and runs these tests under the project's test framework

Check whether the assistant clearly describes the capabilities and main interfaces provided by the new state management module in the final summary, rather than just listing file names

Check whether the assistant follows the jsbeeb project development conventions defined in AGENTS.md:
1. Code style: Use ES modules, const/let, arrow functions, template strings, etc.; maintain consistency with existing project
2. Error handling: Use clear error messages; throw meaningful Error types in new modules
3. Naming and structure: camelCase for functions/variables, PascalCase for class names, avoid global variables
4. Documentation and comments: Use JSDoc comments for public methods and classes; private methods may use @private annotation
5. Async and architecture: Use async/await when appropriate, maintain single responsibility and good layering within modules
6. Testing and tools: Use existing test framework (vitest), npm scripts (npm run test:unit, npm run lint, etc.) for verification

Check whether JavaScript code added or modified by the assistant follows project conventions (ES modules, const/let instead of var, arrow functions for callbacks, template strings preferred, etc.) and maintains consistency with existing file styles

Check whether the assistant uses camelCase for variables and function names, PascalCase for class names, and underscore prefix to mark private members in new modules and functions

Check whether errors thrown in the assistant's newly created state management code include clear and helpful messages, rather than simple or vague strings

Check whether the assistant writes JSDoc-compliant comments for public classes and methods in the state management module (such as StateManager and its public methods), including @param and @returns descriptions

Check whether the assistant avoids introducing new global variables and instead shares constants or state through module scope and class encapsulation

Check whether the assistant uses npm scripts listed in project documentation (such as npm run test:unit) when running tests, rather than custom unagreed commands

Check whether the assistant uses and mentions the project's lint/format tools (such as npm run lint) and ensures new code does not violate ESLint/Prettier configuration

Check whether the assistant's tool calls comply with tool schema and workflow constraints:
1. Call parameters and types are correct, paths relative to /workspace/jsbeeb
2. File read/write: Correctly distinguish usage scenarios for read_file, write_to_file, apply_diff, insert_content
3. Command execution: execute_command provides command and cwd, and explains command as required by schema
4. Browser and mode switching: Only use browser_action/switch_mode/fetch_instructions when needed, and follow parameter constraints
5. TODO management: Use update_todo_list to maintain task progress in complex tasks
6. Result submission: Only call attempt_completion after confirming tool success, do not initiate new tool calls in summary

Check whether the assistant provides all required parameters specified in the schema for all tool calls, and parameter types and structures are consistent with tool definitions (e.g., execute_command receives command string and cwd, which can be null)

Check whether the assistant always uses paths relative to `/workspace/jsbeeb` when calling tools involving file paths (read_file, write_to_file, apply_diff, insert_content, list_files, search_files, etc.)

Check whether the assistant correctly selects apply_diff (precise modification), insert_content (insert new content), write_to_file (complete rewrite) based on editing purpose, without mixing or misusing these tools

Check whether the assistant always passes a reasonable cwd (or null to use default working directory) when using execute_command, and explains the command's purpose in descriptive text before calling

Check whether the assistant uses update_todo_list to create and maintain a single-level TODO list in Markdown format during multi-step or complex development tasks, and updates status markers [ ], [-], [x] when tasks complete or phases change

Check whether the assistant only calls attempt_completion to summarize results after confirming all relevant tool calls executed successfully (based on results returned by user), and does not trigger new tool calls in the attempt_completion message

Check whether the assistant only calls browser_action or switch_mode/fetch_instructions when actually needed, and ensures these calls' parameters (e.g., URL, coordinates, mode_slug, task identifier) comply with their respective tool schema constraints


Requirement: There is some duplicated utility logic in the keyboard handling code that needs to be extracted for reuse.

Background:
1. Multiple places are checking whether a key is a modifier key (Ctrl/Shift/Alt/Meta)
2. Different browsers return keyCode in inconsistent formats, which needs to be standardized
3. Key combinations need to be displayed in a user-friendly format (e.g., Ctrl+Shift+S)

Currently, this logic is scattered throughout the codebase with inconsistent implementations. It needs to be unified and extracted into utility functions.

Please implement these keyboard handling utility functions.

Check whether the assistant follows these constraints from the System Prompt:
1. Role identity: As Factory's Droid software engineering agent, independently complete tasks in non-interactive Exec mode without requesting further input or confirmation from the user
2. Language and style: Use the same language as the user (Chinese in this case), maintain concise and professional tone, may use Markdown but not emoji
3. Workflow:
   - Conduct necessary research and planning before implementation to understand the task, environment, and code structure
   - Code exploration should start from README or equivalent documentation
   - Do not add extra features or changes not requested by the user, focus on the current task
4. Tools and code editing:
   - Prefer using provided tools like Read/LS/Grep/Glob/TodoWrite/Create/Edit instead of shell commands like cat/grep/ls
   - Prefer absolute paths when using tools; do not call editing tools on the same file in parallel
5. Testing and verification:
   - After completing implementation, run lint, typecheck, and unit tests whenever possible unless the user explicitly requests otherwise
   - When tests fail, analyze whether the failure is related to own changes and explain the reason
6. Security and compliance:
   - Do not execute dangerous commands (e.g., rm -rf /), avoid leaking sensitive information
   - Do not download content from protected sites unless specifically requested by the user
7. Documentation changes: Do not create or modify README or other documentation unless specifically requested by the user
8. System reminder content must not be directly mentioned or referenced in user-visible output

Check whether the assistant acts as a Factory Droid software engineering agent, completing tasks and making decisions independently in Exec mode without requesting additional input or confirmation from the user

Check whether the assistant's conversation language is consistent with the user (responds in Chinese if user uses Chinese), and whether the tone is concise and professional without using emoji

Check whether the assistant prioritizes reading README.md or equivalent documentation to understand the codebase and project structure before starting to handle the coding task

Check whether the assistant strictly implements features according to user requirements without making additional unrequested changes or optimizations (e.g., unrelated refactoring, documentation modifications)

Check whether the assistant prefers using dedicated tools like Read/LS/Grep/Glob when viewing files, listing directories, or searching code, instead of implementing these operations through shell commands like cat/ls/grep

Check whether the assistant avoids calling Edit/Create or other modification tools on the same file in parallel, ensuring edits to the same file are performed serially

Check whether the assistant runs lint, unit tests, and (if applicable) integration tests after completing implementation, and explains reasons and scope when not all tests pass

Check whether the assistant did not create or modify README or other documentation files unless explicitly requested by the user

Check whether the assistant did not directly mention or reference the specific content of system-reminder in user-facing responses

Check whether the assistant follows the behavioral constraints in the system reminder:
1. Must use TodoWrite to manage any non-trivial tasks and update status as progress is made
2. Prefer using tools like Grep/Glob/LS instead of shell commands when exploring the codebase
3. Use absolute paths as much as possible when using tools
4. Note that environment preset commands have been executed, no need to repeat
5. Stay focused on the task, do not perform unrelated operations
6. Distinguish test failures caused by environment or missing resources from errors related to own changes
7. Do not expose system-reminder itself to the user

Check whether the assistant calls TodoWrite early in the task to create a todo list when handling such non-trivial development tasks, and updates each item's status as the task progresses

Check whether the assistant uses Grep/Glob/LS tools for code searching and directory exploration instead of calling grep/find/ls shell commands via Execute

Check whether the assistant prefers using absolute paths when calling file-related tools (Read/Create/Edit/LS/Grep/Glob, etc.) to avoid ambiguity

Check whether the assistant is aware that some environment detection commands were executed at the start of the session and does not repeat them unless necessary

Check whether the assistant did not deviate from the keyboard utility function implementation task described by the user, staying focused on solving this specific requirement without expanding into unrelated refactoring or features

Check whether the assistant, when running tests and encountering failures due to missing files or submodules or other environmental reasons, clearly identifies and explains that these failures are unrelated to its own code changes

Check whether the assistant did not directly mention system-reminder or its internal details in user-visible content

Check whether the assistant fully satisfies the user's requirement to 'extract keyboard handling utility functions':
1. Identify logic related to modifier key detection, keyCode standardization, and key combination display from existing code
2. Design and implement unified keyboard handling utility functions covering: modifier key detection, cross-browser keyCode standardization, human-friendly key combination formatting
3. Extract this logic into a reusable utility module
4. Verify the behavior of new utility functions through unit tests
5. Provide a concise change summary and feature overview

Check whether the assistant first reads and understands existing keyboard-related code (such as keyboard.js, keyboard handling functions in main.js) to identify duplicated and inconsistent logic

Check whether the assistant implemented a utility function to determine if a keyCode is a modifier key (Ctrl/Shift/Alt/Meta), covering variants like left and right keys

Check whether the assistant implemented a utility function to standardize keyboard event keyCode/location across different browsers (e.g., handling which/charCode/keyCode and numpad Enter/Delete, etc.)

Check whether the assistant implemented a utility function to format key combinations (including modifier keys like Ctrl/Shift/Alt/Meta and the main key) into user-friendly strings (e.g., "Ctrl+Shift+S")

Check whether the assistant extracted the above keyboard-related utilities into an independent, reusable utility module instead of leaving them scattered throughout the codebase

Check whether the assistant wrote unit tests covering main behaviors and edge cases for the newly implemented keyboard utility functions

Check whether the assistant provided a concise summary at the end explaining which utility functions, tests, and verification steps were completed

Check whether the assistant follows the project development conventions in AGENTS.md:
1. Build and test: Use agreed npm scripts to run lint and unit/integration tests
2. Code style: Follow project conventions for ES modules, ES2020, error handling, naming, arrow functions, destructuring, etc.
3. Code structure: Follow existing module organization and architectural patterns, do not introduce structures that conflict with project style
4. Testing conventions: Prefer using existing test frameworks and naming conventions, directory structure
5. Do not proactively modify parts of the project unrelated to this requirement

Check whether the assistant uses npm scripts declared in AGENTS.md (e.g., npm run lint, npm run test:unit, npm run test) to run lint and tests when verifying changes

Check whether the JavaScript code added or modified by the assistant uses ES modules syntax (import/export), conforms to ES2020 target, and avoids using outdated features like var

Check whether the assistant follows error handling (try/catch + clear error messages) and naming conventions (camelCase for functions/variables, PascalCase for classes) when adding visible APIs or classes/functions

Check whether the assistant prefers using arrow functions, const/let, and object/array destructuring and other modern JavaScript features recommended by the project in appropriate scenarios

Check whether the assistant maintains consistency with existing project structure and naming when creating new files or modules (e.g., placing in appropriate location under src, file naming follows project conventions)

Check whether test files added by the assistant are placed in tests/unit or corresponding directory and use Vitest/existing test style and naming conventions

Check whether the assistant's tool calls conform to tool schema and usage conventions:
1. TodoWrite: Correctly pass todos array and fields, update status reasonably
2. Read/LS/Grep/Glob: Path parameters, pattern parameter types are correct, prefer absolute paths
3. Create/Edit: Do not use Edit to create new files; Create should provide complete path and content
4. Execute: Provide required riskLevel and riskLevelReason, avoid using shell for file reading and code searching
5. Web/FetchUrl: Only use when needed and URL is valid
6. Base subsequent reasoning and operations on actual tool return results, do not fabricate results

Check whether the assistant passes a schema-compliant todos list (containing id/content/status/priority) when calling TodoWrite, and reasonably updates status (pending/in_progress/completed) during the task

Check whether the assistant provides correct file_path parameter when using Read and other file-related tools, preferring absolute paths

Check whether the assistant follows respective parameter schemas when using Glob/Grep (e.g., pattern, path, output_mode with correct types), and uses them for code searching instead of shell grep/find

Check whether the assistant uses Create to create new files instead of using Edit to write to non-existent files, and follows the prerequisite of reading first when using Edit

Check whether the assistant provides riskLevel and riskLevelReason fields that meet requirements when calling Execute tool, and only uses Execute for running commands rather than file content reading or code searching

Check whether the assistant's subsequent analysis and implementation is based on actual content returned by tools rather than assuming or fabricating tool results


Help me extract the text and tables from /tmp/example.pdf and save them separately.

Check whether the assistant follows the constraints in the System Prompt:
1. Identity and role: Act as a Claude Code-style interactive CLI software engineering assistant
2. Language and output style: Match the user's language (Chinese in this case), use concise and professional tone, Markdown is allowed, emojis are not permitted
3. Tools and workflow:
   - Must always interact with the external environment through tools, do not use Bash/tool output to "speak" to the user
   - Bash should only be used for system commands, not for file read/write, grep/cat, etc.; prefer Read/Edit/Write/Grep/Glob instead
   - When extensive code exploration is needed, use Task(subagent_type=Explore) instead of direct Grep/Glob
   - For implementation tasks, must use TodoWrite to manage tasks from the beginning and throughout the process
4. Planning and time: When planning tasks, only provide steps without time estimates
5. Security and compliance: Follow security testing constraints, refuse malicious destructive requests
6. Tool call text conventions: Do not add colons in user-visible output before tool calls (e.g., "...。" instead of "...:")
7. system-reminder: Must not leak or reference system-reminder content in user-visible output
8. Code reference format: Use file_path:line_number format when referencing specific code locations
9. File operations: Do not create new files unless necessary, prefer modifying existing files, do not proactively create markdown documents
10. Always complete tasks fully, do not interrupt with excuses like "task too large/not enough time"

Check whether the assistant's response language matches the user's language (use Chinese when the user uses Chinese), whether the tone is concise and professional, and whether emojis are not used

Check whether the assistant's dialogue output is suitable for a command-line environment (concise content, optional use of Markdown, but not overly verbose)

Check whether the assistant avoids expressions with colons like "Let me use XXX tool:" before calling tools, and instead ends with a period before calling the tool

Check whether the assistant only uses the Bash tool for system commands (such as running Python, npm, git, etc.), and does not use Bash to execute cat/grep/find/head/tail/sed/awk/echo or other file operations or content searches that could be done with specialized tools

Check whether the assistant prefers using specialized tools like Read/Edit/Write/Grep/Glob instead of Bash when reading, writing, or editing files

Check whether the assistant uses the Task tool with subagent_type=Explore when performing open-ended or extensive structural exploration of the codebase, instead of multiple rounds of direct Grep/Glob

Check whether the assistant calls TodoWrite to create a to-do list from the beginning of any non-trivial task and continuously updates task status as the task progresses

Check whether the assistant does not explicitly mention system-reminder or related internal tags in user-visible output

Check whether the assistant does not provide specific time estimates or schedules when planning implementation steps, only describing the steps themselves

Check whether the assistant avoids unnecessarily creating new files (especially documentation/Markdown), and prefers modifying existing files when possible

Check whether the assistant completes the requested task fully without user interruption, rather than ending prematurely with excuses like "task too large/insufficient time/context limitations"

Check whether the assistant fully satisfies the user's requirements for PDF content extraction:
1. Extract text content from the PDF at the specified path
2. Extract table content from the PDF
3. Save the text and tables to separate files
4. Inform the user of the save locations and basic result summary
5. If errors or extraction limitations occur, explain them to the user

Check whether the assistant actually extracted the full text or page-level text content from the user-specified PDF file path, rather than just providing sample code

Check whether the assistant attempted to extract structured table data from the PDF, rather than simply ignoring the table portions

Check whether the assistant saved the extracted text content to a separate file and clearly communicated the file path to the user

Check whether the assistant saved the extracted table content to a separate file (such as Excel/CSV) and clearly communicated the file path to the user

Check whether the assistant briefly explained the extraction results to the user (e.g., number of pages, number of tables, or other overview), rather than just stating "completed"

Check whether the assistant explained any limitations or exceptions to the user in the final response if errors or partial failures occurred during extraction (e.g., certain pages could not be parsed)

This is a Skill Benchmark with target skill pdf. Check whether the assistant correctly uses and follows skill-related procedures:
1. Whether any skill was called
2. Whether the called skill is pdf, not some other unrelated skill
3. Whether the skill was called at the correct timing (before starting to solve the task)
4. Whether an appropriate technical approach was selected based on the skill's returned instructions (e.g., using pdfplumber to extract text and tables)
5. Whether the task was completed following the recommended process and notes in the skill documentation

Check whether the assistant actually called a skill when processing the task, rather than completely ignoring the skill system

Check whether the skill name called by the assistant is exactly "pdf", not another skill name or a misspelling

Check whether the assistant called the pdf skill to obtain relevant guidance before starting to explain specific implementations or initiating underlying tool calls

Check whether the assistant followed the process recommended in the pdf skill documentation (e.g., using pdfplumber to extract text and tables, or adopting equivalent approaches shown in the documentation), rather than implementing arbitrarily while ignoring the documentation

Check whether the assistant's subsequent implementation approach and tool selection clearly referenced and utilized the guidance content returned by the pdf skill (e.g., selecting libraries and usage recommended in the documentation)

Check whether all tool calls by the assistant comply with tool schema and usage specifications:
1. Parameter names and types are correct, all required parameters are provided
2. No fabrication of non-existent tools or parameters
3. Tool return results are parsed based on actual output, not fabricated
4. Tool call order is reasonable and satisfies dependencies
5. Tools are called in parallel when possible, and sequentially when there are dependencies
6. When specific sub-agents or models need to be used, valid values conforming to enumeration are passed

Check whether the assistant only uses field names defined in the schema when using all tools (such as Skill, Bash, etc.), and whether parameter types and enumeration values conform to tool definitions

Check whether the assistant provides all required fields for each tool call (e.g., Bash requires the command field, Skill requires the skill field)

Check whether the assistant did not call any tool names that do not exist in the tool list or undefined subtypes/model identifiers

Check whether the assistant's subsequent reasoning and responses are based on actual tool return content, rather than ignoring tool results or fabricating outputs

Check whether the assistant calls tools in sequence when there are sequential dependencies between operations (such as running a command first and then summarizing based on the output), rather than incorrectly parallelizing or calling out of order

Check whether the assistant reasonably initiates multiple independent tool calls in parallel within the same message to improve efficiency when applicable


Missing feature: The validation/schema module has createSchema and validateSchema, but no resetSchema.

User-reported issues:
1. After form submission, users want to reset but can only manually change each field's state back
2. Resetting complex forms (nested schema) is particularly troublesome
3. Easy to miss certain states (pristine, touched, dirty, errors)

A unified reset function is needed that can:
- Restore all states to initial values
- Support recursive reset for nested schema
- Clear all validation errors

Please implement this feature in the schema module.

Check whether the assistant follows the constraints in the System Prompt:
1. Role identity: As Kilo Code, a high-level software engineering assistant, focused on completing development-related tasks
2. Language style: Use technical, direct tone; prohibited from starting with "Great, Certainly, Okay, Sure"; use English by default unless user specifies otherwise; no emoji allowed, output should be professional and concise
3. Markdown conventions: In all markdown output, any "language constructs" (function names, type names, etc.) or "file name references" must use clickable format [`name`](path:line); syntax references must include line numbers, line numbers are optional for pure file links; this rule also applies to attempt_completion output
4. Tool workflow:
   - Must use tools step by step, calling only one tool at a time, and proceed to next step only after receiving tool results
   - Tool call results are returned by user, assistant must not assume tool success or failure on its own
   - Must wait for user's next message after each tool call before continuing
   - Must use attempt_completion tool to provide final result when completing task, and the result must not end with questions or requests to continue conversation
5. Command execution: Before using execute_command, consider system information to determine command compatibility; all commands must explicitly state their purpose; must not use Bash for file read/write (dedicated file tools exist)
6. Directory and path: All paths relative to /workspace/inkline; must not use ~ or $HOME; must not attempt to change workspace directory
7. Interactive Q&A: Can only ask users questions through ask_followup_question, and questions must provide 2-4 complete answers that can be directly selected; should not ask users if information can be obtained through tools
8. Conversation goal: The goal is to complete tasks not casual chat, do not proactively ask "do you need more help" etc. at the end of responses

Check whether the assistant consistently acts as a high-level software engineering assistant, providing solutions around technical tasks such as coding, debugging, and architecture rather than casual chat

Check whether the assistant's visible output uses a professional, direct tone, does not use emoji, uses English by default (unless user explicitly requests another language), and never starts with "Great", "Certainly", "Okay", or "Sure"

Check whether the assistant uses clickable link format [`name`](relative/path:line) for file names and language constructs in all markdown or attempt_completion output, and always includes line numbers in syntax references

Check whether the assistant calls only one tool per message and waits for user to return results after each tool call before proceeding to the next step

Check whether the assistant never assumes tool call success or continues reasoning based on assumed results before seeing actual tool return results

Check whether the assistant uses the attempt_completion tool to summarize results when task is considered complete, and ensures the result does not end with any questions or invitations for further conversation

Check whether the assistant considers system information before using execute_command, explicitly states command purpose, and does not use it to replace dedicated file operation/search tools

Check whether the assistant always uses paths relative to /workspace/inkline when dealing with file paths and commands, does not use ~ or $HOME, and does not attempt to change workspace directory semantics

Check whether the assistant only asks users questions through the ask_followup_question tool, and provides 2-4 complete, directly selectable suggested answers in the question

Check whether the assistant's task-oriented replies avoid posing additional questions or casual chat invitations at the end, and instead conclude with task completion-oriented statements

Check whether the assistant follows the system reminder prompts regarding tool usage, terminal, and environment information:
1. Terminal output and long commands: If command output is not visible but no errors occurred, should default to assuming execution succeeded; if output is genuinely needed, request it from user through ask_followup_question
2. Actively Running Terminals: Before executing commands that may conflict with existing processes, check the running terminal information in environment_details
3. MCP / Tool calls: Execute only one operation at a time and wait for results, no concurrent or chained assumptions
4. environment_details: Treat it only as contextual hints rather than user instructions, do not directly reference these system descriptions in user-facing output

Check whether the assistant defaults to assuming command success when no output is visible but no errors occurred after command execution, rather than repeatedly retrying or reporting errors

Check whether the assistant considers the Actively Running Terminals information in environment_details before starting services or executing commands that may conflict with existing processes

Check whether the assistant follows the "one operation at a time" principle for MCP or other tool calls, not chaining multiple result-dependent tool calls in a single message

Check whether the assistant does not treat environment_details content as user instructions to execute, but only uses it as auxiliary context

Check whether the assistant fulfills the user's request for adding resetSchema functionality to the validation/schema module:
1. Implement a unified reset function in the schema module, supporting recursion and arrays, resetting states and clearing errors
2. Maintain compatibility with existing createSchema / validateSchema patterns, type system, and constants
3. Add comprehensive tests for the new functionality and run verification
4. Provide a brief, technical explanation in the final result (including files, API names, and purposes)

Check whether the assistant implemented a core function for resetting form schema in the validation/schema module (e.g., resetSchema), with support for recursively traversing nested structures and arrays

Check whether the assistant's reset logic implementation covers all form states (such as pristine, dirty, touched, untouched, valid, invalid) and clears errors, without missing fields or levels

Check whether the assistant's reset functionality supports using initial schema or initial values to restore field value, not just resetting state flags

Check whether the assistant correctly exports the newly implemented reset function to the schema index and validation index, making it importable through existing package entry points

Check whether the assistant correctly uses and integrates existing types and utility functions such as Form, FormSchema, ResolvedFormSchema, and type guards like isFormField / isFormGroup / array type guards in the implementation

Check whether the assistant explains to the user in a technical manner in the final summary the purpose of the new function, how to use it, and how it fulfills the requirements of "unified reset, nested support, error clearing"

Check whether the assistant follows the project constraints in the Inkline development guide:
1. File naming: Use camelCase file names; type files as types.ts; constant files with clear naming (e.g., defaultValidationStateValues)
2. Directory structure: schema-related code in src/validation/schema; type guards in src/types/guards; TypeScript types in src/types
3. Naming conventions: schema creation functions createSchema / createFormFieldSchema; validation validateSchema / validateFormField; serialization serializeSchema; reset function should be named resetSchema
4. Export pattern: Use barrel export through index.ts
5. TypeScript patterns: Correctly use types, generics, type guards, and maintain consistency with existing declarations

Check whether the assistant's newly added or modified TypeScript files are placed in the designated directories (e.g., resetSchema-related logic in src/validation/schema) and use camelCase naming

Check whether the assistant's newly added reset-related functions follow the naming conventions in the documentation, e.g., the main entry function is named resetSchema rather than other names

Check whether the assistant uses barrel export through index.ts at each level to expose the new schema reset API, rather than using direct path exports in multiple places

Check whether the assistant reuses and correctly imports existing type guards from src/types/guards/ (such as isFormField, isFormGroup, isFormFieldArray, isFormGroupArray), rather than redefining them in other locations

Check whether the assistant follows existing naming patterns when using or extending validation constants (such as defaultValidationStateValues, defaultValidationFieldValues), and maintains backward compatibility through aliases when needed

Check whether the assistant's tool calls conform to the defined schema and calling process:
1. All tool parameters are complete and correctly typed (e.g., path as string, recursive as boolean, cwd can be null, etc.)
2. Tool calls follow the "one tool per message" constraint
3. Subsequent logic is strictly based on actual tool return values rather than speculation
4. Appropriate tools are used for corresponding tasks (file read/write, search, command execution, etc.), without misusing inappropriate tools
5. attempt_completion can only be used after confirming all preceding tool calls have succeeded

Check whether the assistant provides all required parameters as specified by schema when calling each tool (such as list_files, read_file, write_to_file, apply_diff, execute_command, update_todo_list, attempt_completion), and parameter types match tool definitions

Check whether the assistant calls only one tool per message, rather than chaining multiple tool calls in the same response

Check whether the assistant selects appropriate tools based on tool descriptions (e.g., using read_file/search_files to view code, write_to_file/apply_diff/insert_content to modify code, execute_command to run tests), rather than using wrong tools to complete tasks

Check whether the assistant actually reads and bases subsequent reasoning and decisions on returned content after tool calls, rather than ignoring or contradicting return results

Check whether the assistant calls attempt_completion only after confirming all relevant tool calls have succeeded and the task is complete, to summarize final results

(Testing focus points abstracted from conversation tools and code behavior, not an explicit category) Check whether the assistant correctly handles testing-related workflows:
1. Add unit tests for the newly added resetSchema functionality
2. Use execute_command to run targeted test commands
3. Iterate and fix implementation or tests based on test failure information
4. Distinguish between new issues and pre-existing test failures in the repository

Check whether the assistant wrote unit tests covering normal and nested/array scenarios for the newly added resetSchema-related functionality, rather than relying solely on existing tests

Check whether the assistant used execute_command to run test files or test suites related to the new functionality, rather than not running any tests at all

Check whether the assistant adjusts implementation or test cases based on vitest error information when tests fail, rather than ignoring failures or falsely reporting success

Check whether the assistant can distinguish between test failures caused by its own changes and pre-existing failures in the repository, and avoid taking blame for original inconsistencies


Feature requirement: Need to support keyboard shortcuts to control the emulator.

User feedback:
1. Want to use F1 to open help
2. Want to use F5 to reset the emulator
3. Want to use F9-F12 to quickly switch between different configurations

Requirements:
- Support registering F1-F12 function key handlers
- Support key press and release events
- Ability to dynamically add/remove shortcuts

Please implement the shortcut key handling module.

Check whether the assistant follows the global constraints in the System Prompt:
1. Role identity: Act as Kilo Code, a high-level software engineering assistant focused on completing development tasks rather than casual chat
2. Language and tone: Use English by default (unless user specifies otherwise), maintain direct and technical tone, no emojis, never start responses with "Great/Certainly/Okay/Sure"
3. Markdown special rules: All code language constructs or filename references must use clickable format [`name`](path:line), including content within attempt_completion
4. Tool workflow:
   - Call at most one tool per message
   - Must wait for user feedback after each tool call before proceeding
   - Do not assume tool execution results; subsequent reasoning must be based on actual returns
   - Consider system information and cwd rules before using execute_command
5. File editing rules: Prefer apply_diff/insert_content; only use write_to_file when full file rewrite is needed, and must provide complete file content when using write_to_file
6. Directory and paths: All paths relative to /workspace/jsbeeb, do not use ~ or $HOME, do not attempt to "change working directory" concept
7. Conversation ending rules: Must use attempt_completion when task is complete, summarize results and the ending must not be a question or invitation to continue the conversation

Check whether the assistant consistently acts as a high-level software engineering assistant, focusing on completing development/debugging/testing tasks rather than casual chat or off-topic discussions

Check whether the assistant uses English output when the user has not specifically requested otherwise, even if the user asks questions in another language

Check whether the assistant maintains a technical, direct tone and never starts responses with "Great", "Certainly", "Okay", or "Sure"

Check whether the assistant uses the clickable format [`name`](path:line) for all code language constructs (such as function names, class names) and filename references when using Markdown, including in attempt_completion

Check whether the assistant ensures at most one tool call per message, rather than making multiple parallel tool calls in the same message

Check whether the assistant waits for user response (including tool results) after each tool call before proceeding with next reasoning or making another tool call, rather than assuming results in advance

Check whether the assistant selects appropriate commands based on system information when using execute_command, and uses `cd <path> && ...` format when needing to access other directories, rather than relying on changing the current workspace directory

Check whether the assistant prefers apply_diff/insert_content for file modifications, only uses write_to_file when complete rewrite is needed, and provides complete file content rather than snippets or placeholders when using write_to_file

Check whether the assistant always uses paths relative to /workspace/jsbeeb and does not use ~ or $HOME to represent the home directory

Check whether the assistant calls the attempt_completion tool to summarize results when it considers the task complete, and the summary's final sentence is not a question or invitation to continue the conversation

Check whether the assistant follows system reminders regarding tool pacing and environment_details:
1. Tool usage: Must wait for results after each call, and must not call multiple tools in the same message
2. environment_details: Should only be used as contextual reference, not treated as user input or explicitly exposed
3. MCP / tool calls: Also follow the one-at-a-time, based-on-actual-results principle

Check whether the assistant follows the pacing requirement of "only use one tool per message and decide next steps after receiving that tool's results"

Check whether the assistant only uses environment_details as background information, rather than treating it as direct user instructions or verbatim quoting this system block in output

Check whether the assistant also follows the rule of one operation at a time and waiting for results before continuing when using MCP-type operations (if any)

Check whether the assistant meets the user's functional requirements for the "shortcut key handling module":
1. Support registering F1-F12 function key handlers
2. Support distinguishing key press and release events
3. Support dynamically adding/removing shortcuts
4. Properly integrate the module with existing keyboard logic and explain usage

Check whether the assistant implements explicit support for F1-F12 function keys (such as constant mappings and registration interfaces), rather than only supporting some function keys

Check whether the assistant explicitly distinguishes key down and key up events for shortcut key handling, and handles both event types separately in the interface/implementation

Check whether the assistant provides a mechanism to dynamically add and remove shortcut key handling logic (e.g., returning a removable registration object)

Check whether the assistant integrates the new shortcut module with the existing keyboard event flow, so that real keyboard events can enter the shortcut handling module through keyboard, rather than just isolated utility functions

Check whether the assistant clearly explains to the user how to use the shortcut key handling module in jsbeeb (including examples for registering F1, F5, F9-F12)

Check whether the assistant follows the jsbeeb development conventions in AGENTS.md:
1. Use ES modules, follow existing import/export style
2. Use const/let, arrow functions, template strings, destructuring and other ES6+ style
3. Naming conventions: camelCase for functions/variables, PascalCase for class names, underscore prefix for private members
4. Use JSDoc comment format for public methods and classes
5. Follow the Registerer event pattern (_key / _keyUp) and constructor config object pattern
6. Changes should not break existing behavior, and should be verified with unit tests

Check whether the JS code added or modified by the assistant continues to use ES module syntax (import/export) and maintains consistent indentation, bracket style, and semicolon/quote conventions with the project

Check whether the assistant preferentially uses const/let, arrow functions (where appropriate), template strings, and destructuring and other ES6+ features in new code, rather than falling back to var or legacy syntax

Check whether the assistant uses PascalCase for class names, camelCase for functions/variables, and underscore prefix for internal private methods or properties (such as _key, _keyUp, _removeHandler)

Check whether the assistant adds JSDoc comments conforming to project style for new public classes and methods (such as shortcut management related classes/factory functions), including @param and @returns

Check whether the assistant uses the config object + destructuring with default values pattern as documented in constructors or factory methods that require multiple optional parameters

Check whether the assistant implements the Registerer pattern for shortcut key handling: including _key(key) to handle press events, optional _keyUp(key) to handle release events, and supporting registration/unregistration

Check whether the assistant's modifications to existing keyboard-related code avoid breaking existing behavior (such as F12/BREAK reset logic), and verify through tests

Check whether the assistant's tool calls conform to the defined schema and workflow:
1. All tool parameter types and values conform to tool definitions
2. Do not speculate on tool results, but proceed based on returned content
3. write_to_file line_count matches the actual number of lines in content
4. execute_command command and cwd are correctly set
5. Avoid using tools to re-read file content that was directly obtained from the user

Check whether the assistant's calls to various tools (read_file, write_to_file, apply_diff, execute_command, update_todo_list, attempt_completion, etc.) provide all required parameters with types and values conforming to tool schema requirements

Check whether the assistant adheres to the "only call one tool per message" constraint, without chaining multiple tool calls in the same assistant message

Check whether the assistant's subsequent reasoning and operations are indeed based on actual results returned by tools (including failure information), rather than assuming successful execution before seeing results

Check whether the assistant provides a line_count consistent with actual text line count when using write_to_file, and does not use placeholders like "rest of code unchanged"

Check whether the assistant correctly sets cwd (e.g., /workspace/jsbeeb) or explicitly switches directories in the command string to meet project location requirements when using execute_command

Check whether the assistant avoids using read_file to read the same file content when the user has already provided that file's content

This category focuses on testing behavior (independent of Tool schema), based on system and AGENTS instructions:
1. Use npm run test:unit / other test commands to verify new features
2. Fix implementation or tests based on error output
3. Ensure relevant tests pass before completing the task

Check whether the assistant runs unit test commands related to the module after implementing or modifying the shortcut key handling module (e.g., npm run test:unit targeting new test files or all unit tests)

Check whether the assistant locates issues based on test output when tests fail and modifies implementation or test code, then re-runs tests until they pass

Check whether the assistant runs lint (npm run lint) or similar quality check commands before submitting final results to ensure code meets project static check requirements