sta-s2z

Untitled

Apr 15th, 2026
68
0
Never
4
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 86.84 KB | None | 0 0
  1. {
  2. "timestamp": "2026-04-15T22:09:47.027Z",
  3. "request": {
  4. "model": "coder-model",
  5. "messages": [
  6. {
  7. "role": "system",
  8. "content": "You are Qwen Code, an interactive CLI agent developed by Alibaba Group, specializing in software engineering tasks. Your primary goal is to help users safely and efficiently, adhering strictly to the following instructions and utilizing your available tools.\n\n# Core Mandates\n\n- **Conventions:** Rigorously adhere to existing project conventions when reading or modifying code. Analyze surrounding code, tests, and configuration first.\n- **Libraries/Frameworks:** NEVER assume a library/framework is available or appropriate. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', 'build.gradle', etc., or observe neighboring files) before employing it.\n- **Style & Structure:** Mimic the style (formatting, naming), structure, framework choices, typing, and architectural patterns of existing code in the project.\n- **Idiomatic Changes:** When editing, understand the local context (imports, functions/classes) to ensure your changes integrate naturally and idiomatically.\n- **Comments:** Add code comments sparingly. Focus on *why* something is done, especially for complex logic, rather than *what* is done. Only add high-value comments if necessary for clarity or if requested by the user. Do not edit comments that are separate from the code you are changing. *NEVER* talk to the user or describe your changes through comments.\n- **Proactiveness:** Fulfill the user's request thoroughly. When adding features or fixing bugs, this includes adding tests to ensure quality. Consider all created files, especially tests, to be permanent artifacts unless the user says otherwise.\n- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If asked *how* to do something, explain first, don't just do it.\n- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.\n- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.\n- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.\n\n# Task Management\nYou have access to the todo_write tool to help you manage and plan tasks. Use these tools VERY frequently to ensure that you are tracking your tasks and giving the user visibility into your progress.\nThese tools are also EXTREMELY helpful for planning tasks, and for breaking down larger complex tasks into smaller steps. If you do not use this tool when planning, you may forget to do important tasks - and that is unacceptable.\n\nIt is critical that you mark todos as completed as soon as you are done with a task. Do not batch up multiple tasks before marking them as completed.\n\nExamples:\n\n<example>\nuser: Run the build and fix any type errors\nassistant: I'm going to use the todo_write tool to write the following items to the todo list: \n- Run the build\n- Fix any type errors\n\nI'm now going to run the build using Bash.\n\nLooks like I found 10 type errors. I'm going to use the todo_write tool to write 10 items to the todo list.\n\nmarking the first todo as in_progress\n\nLet me start working on the first item...\n\nThe first item has been fixed, let me mark the first todo as completed, and move on to the second item...\n..\n..\n</example>\nIn the above example, the assistant completes all the tasks, including the 10 error fixes and running the build and fixing all errors.\n\n<example>\nuser: Help me write a new feature that allows users to track their usage metrics and export them to various formats\n\nA: I'll help you implement a usage metrics tracking and export feature. Let me first use the todo_write tool to plan this task.\nAdding the following todos to the todo list:\n1. Research existing metrics tracking in the codebase\n2. Design the metrics collection system\n3. Implement core metrics tracking functionality\n4. Create export functionality for different formats\n\nLet me start by researching the existing codebase to understand what metrics we might already be tracking and how we can build on that.\n\nI'm going to search for any existing metrics or telemetry code in the project.\n\nI've found some existing telemetry code. Let me mark the first todo as in_progress and start designing our metrics tracking system based on what I've learned...\n\n[Assistant continues implementing the feature step by step, marking todos as in_progress and completed as they go]\n</example>\n\n# Asking questions as you work\n\nYou have access to the ask_user_question tool to ask the user questions when you need clarification, want to validate assumptions, or need to make a decision you're unsure about. When presenting options or plans, never include time estimates - focus on what each option involves, not how long it takes.\n\n# Primary Workflows\n\n## Software Engineering Tasks\nWhen requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this iterative approach:\n- **Plan:** After understanding the user's request, create an initial plan based on your existing knowledge and any immediately obvious context. Use the 'todo_write' tool to capture this rough plan for complex or multi-step work. Don't wait for complete understanding - start with what you know.\n- **Implement:** Begin implementing the plan while gathering additional context as needed. Use 'grep_search', 'glob', and 'read_file' tools strategically when you encounter specific unknowns during implementation. Use the available tools (e.g., 'edit', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').\n- **Adapt:** As you discover new information or encounter obstacles, update your plan and todos accordingly. Mark todos as in_progress when starting and completed when finishing each task. Add new todos if the scope expands. Refine your approach based on what you learn.\n- **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.\n- **Verify (Standards):** VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.\n\n**Key Principle:** Start with a reasonable plan based on available information, then adapt as you learn. Users prefer seeing progress quickly rather than waiting for perfect understanding.\n\n- Tool results and user messages may include <system-reminder> tags. <system-reminder> tags contain useful information and reminders. They are NOT part of the user's provided input or the tool result.\n\nIMPORTANT: Always use the todo_write tool to plan and track tasks throughout the conversation.\n\n## New Applications\n\n**Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are 'write_file', 'edit' and 'run_shell_command'.\n\n1. **Understand Requirements:** Analyze the user's request to identify core features, desired user experience (UX), visual aesthetic, application type/platform (web, mobile, desktop, CLI, library, 2D or 3D game), and explicit constraints. If critical information for initial planning is missing or ambiguous, ask concise, targeted clarification questions. Use the ask_user_question tool to ask questions, clarify and gather information as needed.\n2. **Propose Plan:** Formulate an internal development plan. Present a clear, concise, high-level summary to the user. This summary must effectively convey the application's type and core purpose, key technologies to be used, main features and how users will interact with them, and the general approach to the visual design and user experience (UX) with the intention of delivering something beautiful, modern, and polished, especially for UI-based applications. For applications requiring visual assets (like games or rich UIs), briefly describe the strategy for sourcing or generating placeholders (e.g., simple geometric shapes, procedurally generated patterns, or open-source assets if feasible and licenses permit) to ensure a visually complete initial prototype. Ensure this information is presented in a structured and easily digestible manner.\n - When key technologies aren't specified, prefer the following:\n - **Websites (Frontend):** React (JavaScript/TypeScript) with Bootstrap CSS, incorporating Material Design principles for UI/UX.\n - **Back-End APIs:** Node.js with Express.js (JavaScript/TypeScript) or Python with FastAPI.\n - **Full-stack:** Next.js (React/Node.js) using Bootstrap CSS and Material Design principles for the frontend, or Python (Django/Flask) for the backend with a React/Vue.js frontend styled with Bootstrap CSS and Material Design principles.\n - **CLIs:** Python or Go.\n - **Mobile App:** Compose Multiplatform (Kotlin Multiplatform) or Flutter (Dart) using Material Design libraries and principles, when sharing code between Android and iOS. Jetpack Compose (Kotlin JVM) with Material Design principles or SwiftUI (Swift) for native apps targeted at either Android or iOS, respectively.\n - **3d Games:** HTML/CSS/JavaScript with Three.js.\n - **2d Games:** HTML/CSS/JavaScript.\n3. **User Approval:** Obtain user approval for the proposed plan.\n4. **Implementation:** Use the 'todo_write' tool to convert the approved plan into a structured todo list with specific, actionable tasks, then autonomously implement each task utilizing all available tools. When starting ensure you scaffold the application using 'run_shell_command' for commands like 'npm init', 'npx create-react-app'. Aim for full scope completion. Proactively create or source necessary placeholder assets (e.g., images, icons, game sprites, 3D models using basic primitives if complex assets are not generatable) to ensure the application is visually coherent and functional, minimizing reliance on the user to provide these. If the model can generate simple assets (e.g., a uniformly colored square sprite, a simple 3D cube), it should do so. Otherwise, it should clearly indicate what kind of placeholder has been used and, if absolutely necessary, what the user might replace it with. Use placeholders only when essential for progress, intending to replace them with more refined versions or instruct the user on replacement during polishing if generation is not feasible.\n5. **Verify:** Review work against the original request, the approved plan. Fix bugs, deviations, and all placeholders where feasible, or ensure placeholders are visually adequate for a prototype. Ensure styling, interactions, produce a high-quality, functional and beautiful prototype aligned with design goals. Finally, but MOST importantly, build the application and ensure there are no compile errors.\n6. **Solicit Feedback:** If still applicable, provide instructions on how to start the application and request user feedback on the prototype.\n\n# Operational Guidelines\n\n## Tone and Style (CLI Interaction)\n- **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.\n- **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.\n- **Clarity over Brevity (When Needed):** While conciseness is key, prioritize clarity for essential explanations or when seeking necessary clarification if a request is ambiguous.\n- **No Chitchat:** Avoid conversational filler, preambles (\"Okay, I will now...\"), or postambles (\"I have finished the changes...\"). Get straight to the action or answer.\n- **Formatting:** Use GitHub-flavored Markdown. Responses will be rendered in monospace.\n- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls or code blocks unless specifically part of the required code/command itself.\n- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly (1-2 sentences) without excessive justification. Offer alternatives if appropriate.\n\n## Security and Safety Rules\n- **Explain Critical Commands:** Before executing commands with 'run_shell_command' that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).\n- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.\n\n## Tool Usage\n- **File Paths:** Always use absolute paths when referring to files with tools like 'read_file' or 'write_file'. Relative paths are not supported. You must provide an absolute path.\n- **Parallelism:** Execute multiple independent tool calls in parallel when feasible (i.e. searching the codebase).\n- **Command Execution:** Use the 'run_shell_command' tool for running shell commands, remembering the safety rule to explain modifying commands first.\n- **Background Processes:** Use background processes (via `&`) for commands that are unlikely to stop on their own, e.g. `node server.js &`. If unsure, ask the user.\n- **Interactive Commands:** Try to avoid shell commands that are likely to require user interaction (e.g. `git rebase -i`). Use non-interactive versions of commands (e.g. `npm init -y` instead of `npm init`) when available, and otherwise remind the user that interactive shell commands are not supported and may cause hangs until canceled by the user.\n- **Task Management:** Use the 'todo_write' tool proactively for complex, multi-step tasks to track progress and provide visibility to users. This tool helps organize work systematically and ensures no requirements are missed.\n- **Subagent Delegation:** When doing file search, prefer to use the 'agent' tool in order to reduce context usage. You should proactively use the 'agent' tool with specialized agents when the task at hand matches the agent's description.\n- **Remembering Facts:** Use the 'save_memory' tool to remember specific, *user-related* facts or preferences when the user explicitly asks, or when they state a clear, concise piece of information that would help personalize or streamline *your future interactions with them* (e.g., preferred coding style, common project paths they use, personal tool aliases). This tool is for user-specific information that should persist across sessions. Do *not* use it for general project context or information. If unsure whether to save something, you can ask the user, \"Should I remember that for you?\"\n- **Respect User Confirmations:** Most tool calls (also denoted as 'function calls') will first require confirmation from the user, where they will either approve or cancel the function call. If a user cancels a function call, respect their choice and do _not_ try to make the function call again. It is okay to request the tool call again _only_ if the user requests that same tool call on a subsequent prompt. When a user cancels a function call, assume best intentions from the user and consider inquiring if they prefer any alternative paths forward.\n\n## Interaction Details\n- **Help Command:** The user can use '/help' to display help information.\n- **Feedback:** To report a bug or provide feedback, please use the /bug command.\n\n\n# Outside of Sandbox\nYou are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.\n\n\n\n# Executing actions with care\n\nCarefully consider the reversibility and blast radius of actions. Generally you can freely take local, reversible actions like editing files or running tests. But for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding. The cost of pausing to confirm is low, while the cost of an unwanted action (lost work, unintended messages sent, deleted branches) can be very high. For actions like these, consider the context, the action, and user instructions, and by default transparently communicate the action and ask for confirmation before proceeding. This default can be changed by user instructions - if explicitly asked to operate more autonomously, then you may proceed without confirmation, but still attend to the risks and consequences when taking actions. A user approving an action (like a git push) once does NOT mean that they approve it in all contexts, so unless actions are authorized in advance in durable instructions like QWEN.md files, always confirm first. Authorization stands for the scope specified, not beyond. Match the scope of your actions to what was actually requested.\n\nExamples of the kind of risky actions that warrant user confirmation:\n- Destructive operations: deleting files/branches, dropping database tables, killing processes, rm -rf, overwriting uncommitted changes\n- Hard-to-reverse operations: force-pushing (can also overwrite upstream), git reset --hard, amending published commits, removing or downgrading packages/dependencies, modifying CI/CD pipelines\n- Actions visible to others or that affect shared state: pushing code, creating/closing/commenting on PRs or issues, sending messages (Slack, email, GitHub), posting to external services, modifying shared infrastructure or permissions\n- Uploading content to third-party web tools (diagram renderers, pastebins, gists) publishes it - consider whether it could be sensitive before sending, since it may be cached or indexed even if later deleted.\n\nWhen you encounter an obstacle, do not use destructive actions as a shortcut to simply make it go away. For instance, try to identify root causes and fix underlying issues rather than bypassing safety checks (e.g. --no-verify). If you discover unexpected state like unfamiliar files, branches, or configuration, investigate before deleting or overwriting, as it may represent the user's in-progress work. For example, typically resolve merge conflicts rather than discarding changes; similarly, if a lock file exists, investigate what process holds it rather than deleting it. In short: only take risky actions carefully, and when in doubt, ask before acting. Follow both the spirit and letter of these instructions - measure twice, cut once.\n\n\n# Git Repository\n- The current working (project) directory is being managed by a git repository.\n- When asked to commit changes or prepare a commit, always start by gathering information using shell commands:\n - `git status` to ensure that all relevant files are tracked and staged, using `git add ...` as needed.\n - `git diff HEAD` to review all changes (including unstaged changes) to tracked files in work tree since last commit.\n - `git diff --staged` to review only staged changes when a partial commit makes sense or was requested by the user.\n - `git log -n 3` to review recent commit messages and match their style (verbosity, formatting, signature line, etc.)\n- Combine shell commands whenever possible to save time/steps, e.g. `git status && git diff HEAD && git log -n 3`.\n- Always propose a draft commit message. Never just ask the user to give you the full commit message.\n- Prefer commit messages that are clear, concise, and focused more on \"why\" and less on \"what\".\n- Keep the user informed and ask for clarification or confirmation where needed.\n- After each commit, confirm that it was successful by running `git status`.\n- If a commit fails, never attempt to work around the issues without being asked to do so.\n- Never push changes to a remote repository without being asked explicitly by the user.\n\n\n# Examples (Illustrating Tone and Workflow)\n<example>\nuser: 1 + 2\nmodel: 3\n</example>\n\n<example>\nuser: is 13 a prime number?\nmodel: true\n</example>\n\n<example>\nuser: start the server implemented in server.js\nmodel:\n<tool_call>\n<function=run_shell_command>\n<parameter=command>\nnode server.js &\n</parameter>\n<parameter=is_background>\ntrue\n</parameter>\n</function>\n</tool_call>\n</example>\n\n<example>\nuser: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.\nmodel: Okay, I can refactor 'src/auth.py'.\nFirst, I'll analyze the code and check for a test safety net before planning any changes.\n<tool_call>\n<function=glob>\n<parameter=path>\ntests/test_auth.py\n</parameter>\n</function>\n</tool_call>\n<tool_call>\n<function=read_file>\n<parameter=path>\n/path/to/tests/test_auth.py\n</parameter>\n<parameter=offset>\n0\n</parameter>\n<parameter=limit>\n10\n</parameter>\n</function>\n</tool_call>\n(After analysis)\nGreat, 'tests/test_auth.py' exists and covers the core authentication logic. With this safety net in place, I can safely plan the refactoring.\nI'll also confirm 'requests' is a dependency.\n<tool_call>\n<function=read_file>\n<parameter=path>\n/path/to/requirements.txt\n</parameter>\n</function>\n</tool_call>\n(After analysis)\nLooks good, 'requests' is available.\n\nHere's the plan:\n1. Replace the 'urllib' calls with 'requests'.\n2. Add proper 'try...except' error handling for the new network calls.\n3. Remove the old 'urllib' import.\n4. Run the project's linter and tests to verify the changes.\n\n<tool_call>\n<function=edit>\n<parameter=path>\nsrc/auth.py\n</parameter>\n<parameter=old_content>\n(old code content)\n</parameter>\n<parameter=new_content>\n(new code content)\n</parameter>\n</function>\n</tool_call>\nRefactoring complete. Running verification...\n<tool_call>\n<function=run_shell_command>\n<parameter=command>\nruff check src/auth.py && pytest\n</parameter>\n</function>\n</tool_call>\n(After verification passes)\nAll checks passed. This is a stable checkpoint.\nWould you like me to write a commit message and commit these changes?\n</example>\n\n<example>\nuser: Delete the temp directory.\nmodel: I can run `rm -rf /path/to/project/temp`. This will permanently delete the directory and all its contents.\n</example>\n\n<example>\nuser: Write tests for someFile.ts\nmodel:\nOkay, I can write those tests. First, I'll read someFile.ts to understand its functionality.\n<tool_call>\n<function=read_file>\n<parameter=path>\n/path/to/someFile.ts\n</parameter>\n</function>\n</tool_call>\nNow I'll look for existing or related test files to understand current testing conventions and dependencies.\n<tool_call>\n<function=read_file>\n<parameter=path>\n/path/to/existingTest.test.ts\n</parameter>\n</function>\n</tool_call>\n(After reviewing existing tests and the file content)\n<tool_call>\n<function=write_file>\n<parameter=path>\n/path/to/someFile.test.ts\n</parameter>\n</function>\n</tool_call>\nI've written the tests. Now I'll run the project's test command to verify them.\n<tool_call>\n<function=run_shell_command>\n<parameter=command>\nnpm run test\n</parameter>\n</function>\n</tool_call>\n(After verification passes)\nAll checks passed. This is a stable checkpoint.\n</example>\n\n<example>\nuser: Where are all the 'app.config' files in this project? I need to check their settings.\nmodel:\n<tool_call>\n<function=glob>\n<parameter=pattern>\n./**/app.config\n</parameter>\n</function>\n</tool_call>\n(Assuming GlobTool returns a list of paths like ['/path/to/moduleA/app.config', '/path/to/moduleB/app.config'])\nI found the following 'app.config' files:\n- /path/to/moduleA/app.config\n- /path/to/moduleB/app.config\nTo help you check their settings, I can read their contents. Which one would you like to start with, or should I read all of them?\n</example>\n\n# Final Reminder\nYour core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved.\n\n---\n\n--- Context from: ../../.qwen/output-language.md ---\n# Output language preference: Russian\n<!-- qwen-code:llm-output-language: Russian -->\n\n## Rule\nYou MUST always respond in **Russian** regardless of the user's input language.\nThis is a mandatory requirement, not a preference.\n\n## Exception\nIf the user **explicitly** requests a response in a specific language (e.g., \"please reply in English\", \"用中文回答\"), switch to the user's requested language for the remainder of the conversation.\n\n## Keep technical artifacts unchanged\nDo **not** translate or rewrite:\n- Code blocks, CLI commands, file paths, stack traces, logs, JSON keys, identifiers\n- Exact quoted text from the user (keep quotes verbatim)\n\n## Tool / system outputs\nRaw tool/system outputs may contain fixed-format English. Preserve them verbatim, and if needed, add a short **Russian** explanation below.\n--- End of Context from: ../../.qwen/output-language.md ---"
  9. },
  10. {
  11. "role": "user",
  12. "content": [
  13. {
  14. "type": "text",
  15. "text": "This is the Qwen Code. We are setting up the context for our chat.\nToday's date is Thursday, April 16, 2026 (formatted according to the user's locale).\nMy operating system is: linux\nI'm currently working in the directory: /home/sta/Gradle/qwen-gate\nHere is the folder structure of the current working directories:\n\nShowing up to 20 items:\n\n/home/sta/Gradle/qwen-gate/\n├───.gitignore\n├───chat_state.json\n├───config-examples.ini\n├───config.ini\n├───install.sh\n├───main.py\n├───PROTOCOL_DESC.md\n├───qwen_gate.log\n├───README.md\n├───requirements.txt\n├───start.sh\n├───.git/...\n├───.qwen/\n│ └───settings.json\n│ └───...\n├───data/\n├───logs_qwen_cli/\n├───qwen_gate/\n├───temp/\n├───tmp/\n└───venv/"
  16. }
  17. ]
  18. },
  19. {
  20. "role": "assistant",
  21. "content": "Got it. Thanks for the context!"
  22. },
  23. {
  24. "role": "user",
  25. "content": [
  26. {
  27. "type": "text",
  28. "text": "в гите сейчас новый коммит, который конфликтует с последними правками, нужно смержить его так, чтобы из него взялись только неконфликтующие правки с текущей веткой, приоритет тому коду, который сейчас"
  29. }
  30. ]
  31. },
  32. {
  33. "role": "assistant",
  34. "content": "Пользователь хочет выполнить слияние с приоритетом текущего кода, поэтому сначала нужно проверить статус git и понять текущее состояние репозитория.Давайте сначала посмотрим текущее состояние репозитория и поймём ситуацию с конфликтами.\n\n",
  35. "tool_calls": [
  36. {
  37. "id": "call_259fe2cd4a054cfd",
  38. "type": "function",
  39. "function": {
  40. "name": "run_shell_command",
  41. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status && echo \\\"---\\\" && git log -n 5 --oneline\",\"is_background\":\"false\"}"
  42. }
  43. }
  44. ]
  45. },
  46. {
  47. "role": "tool",
  48. "tool_call_id": "call_259fe2cd4a054cfd",
  49. "content": [
  50. {
  51. "type": "text",
  52. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status && echo \"---\" && git log -n 5 --oneline\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n---\nbea1299 (HEAD -> main) new\nbf8c99b finally working, but no context\ndbeabc4 inouttools\ncb912c8 zzz\n521d3ee tools\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3622393"
  53. }
  54. ]
  55. },
  56. {
  57. "role": "assistant",
  58. "content": "Пользователь просит слить новый коммит с текущей веткой, разрешая конфликты в пользу текущего кода. Сначала нужно посмотреть состояние git.Давайте посмотрим состояние репозитория.\n\n",
  59. "tool_calls": [
  60. {
  61. "id": "call_c5fff6307118441a",
  62. "type": "function",
  63. "function": {
  64. "name": "run_shell_command",
  65. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status\",\"is_background\":\"false\"}"
  66. }
  67. }
  68. ]
  69. },
  70. {
  71. "role": "tool",
  72. "tool_call_id": "call_c5fff6307118441a",
  73. "content": [
  74. {
  75. "type": "text",
  76. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3622751"
  77. }
  78. ]
  79. },
  80. {
  81. "role": "assistant",
  82. "content": "Пользователь хочет выполнить слияние, при котором приоритет отдаётся текущей ветке. Сначала нужно понять текущее состояние репозитория — есть ли конфликтующий коммит, на какой ветке мы находимся.Давайте сначала посмотрим текущее состояние репозитория, чтобы понять ситуацию.",
  83. "tool_calls": [
  84. {
  85. "id": "call_f5d510f7660d42fd",
  86. "type": "function",
  87. "function": {
  88. "name": "run_shell_command",
  89. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status\",\"is_background\":\"false\"}"
  90. }
  91. }
  92. ]
  93. },
  94. {
  95. "role": "tool",
  96. "tool_call_id": "call_f5d510f7660d42fd",
  97. "content": [
  98. {
  99. "type": "text",
  100. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3623531"
  101. }
  102. ]
  103. },
  104. {
  105. "role": "assistant",
  106. "content": "Нужно сначала понять состояние репозитория — посмотреть git status, лог коммитов и текущую ветку, чтобы определить, что именно конфликтует и с чем мержить.\nПонял задачу. Сначала посмотрю текущее состояние репозитория.\n\n",
  107. "tool_calls": [
  108. {
  109. "id": "call_d6dbe0859cd74ba6",
  110. "type": "function",
  111. "function": {
  112. "name": "run_shell_command",
  113. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status\",\"is_background\":\"false\"}"
  114. }
  115. }
  116. ]
  117. },
  118. {
  119. "role": "tool",
  120. "tool_call_id": "call_d6dbe0859cd74ba6",
  121. "content": [
  122. {
  123. "type": "text",
  124. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3623641"
  125. }
  126. ]
  127. },
  128. {
  129. "role": "assistant",
  130. "content": "The user wants to merge a new commit that conflicts with current changes. They want to keep their current code as priority and only take non-conflicting changes from the incoming commit. Let me first check git status to understand the current state.Понял задачу. Давайте сначала посмотрим текущее состояние репозитория.\n\n",
  131. "tool_calls": [
  132. {
  133. "id": "call_a5fb7d2584cd412e",
  134. "type": "function",
  135. "function": {
  136. "name": "run_shell_command",
  137. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status\",\"is_background\":\"false\"}"
  138. }
  139. }
  140. ]
  141. },
  142. {
  143. "role": "tool",
  144. "tool_call_id": "call_a5fb7d2584cd412e",
  145. "content": [
  146. {
  147. "type": "text",
  148. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3623809"
  149. }
  150. ]
  151. },
  152. {
  153. "role": "assistant",
  154. "content": "The tool calls seem to not be returning results. Let me try again with git status to understand the current state.",
  155. "tool_calls": [
  156. {
  157. "id": "call_8b805f7c565b49ea",
  158. "type": "function",
  159. "function": {
  160. "name": "run_shell_command",
  161. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status 2>&1\",\"is_background\":\"false\"}"
  162. }
  163. }
  164. ]
  165. },
  166. {
  167. "role": "tool",
  168. "tool_call_id": "call_8b805f7c565b49ea",
  169. "content": [
  170. {
  171. "type": "text",
  172. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status 2>&1\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3623927"
  173. }
  174. ]
  175. },
  176. {
  177. "role": "assistant",
  178. "content": "Команда git status не возвращает результат — нужно проверить, выполняется ли она вообще. Попробую выполнить с таймаутом и посмотреть, что происходит.\n",
  179. "tool_calls": [
  180. {
  181. "id": "call_744d4aeff97344b8",
  182. "type": "function",
  183. "function": {
  184. "name": "run_shell_command",
  185. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && timeout 10 git status 2>&1; echo \\\"EXIT: $?\\\"\",\"is_background\":\"false\"}"
  186. }
  187. }
  188. ]
  189. },
  190. {
  191. "role": "tool",
  192. "tool_call_id": "call_744d4aeff97344b8",
  193. "content": [
  194. {
  195. "type": "text",
  196. "text": "Command: cd /home/sta/Gradle/qwen-gate && timeout 10 git status 2>&1; echo \"EXIT: $?\"\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nEXIT: 0\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3624195"
  197. }
  198. ]
  199. },
  200. {
  201. "role": "assistant",
  202. "content": "The user wants to merge a new commit that conflicts with current changes, keeping current code as priority. Let me first check the git status properly.",
  203. "tool_calls": [
  204. {
  205. "id": "call_3b312f5a41b64647",
  206. "type": "function",
  207. "function": {
  208. "name": "run_shell_command",
  209. "arguments": "{\"command\":\"cd /home/sta/Gradle/qwen-gate && git status\",\"is_background\":\"false\"}"
  210. }
  211. }
  212. ]
  213. },
  214. {
  215. "role": "tool",
  216. "tool_call_id": "call_3b312f5a41b64647",
  217. "content": [
  218. {
  219. "type": "text",
  220. "text": "Command: cd /home/sta/Gradle/qwen-gate && git status\nDirectory: (root)\nOutput: On branch main\nYour branch and 'origin/main' have diverged,\nand have 1 and 2 different commits each, respectively.\n (use \"git pull\" if you want to integrate the remote branch with yours)\n\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git restore <file>...\" to discard changes in working directory)\n modified: qwen_gate.log\n modified: qwen_gate/static/index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nError: (none)\nExit Code: 0\nSignal: 0\nProcess Group PGID: 3624326"
  221. }
  222. ]
  223. }
  224. ],
  225. "tools": [
  226. {
  227. "type": "function",
  228. "function": {
  229. "name": "agent",
  230. "description": "Launch a new agent to handle complex, multi-step tasks autonomously.\nThe Agent tool launches specialized agents (subprocesses) that autonomously handle complex tasks. Each agent type has specific capabilities and tools available to it.\n\nAvailable agent types and the tools they have access to:\n- **general-purpose**: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not confident that you will find the right match in the first few tries use this agent to perform the search for you.\n- **Explore**: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. \"src/components/**/*.tsx\"), search code for keywords (eg. \"API endpoints\"), or answer questions about the codebase (eg. \"how do API endpoints work?\"). When calling this agent, specify the desired thoroughness level: \"quick\" for basic searches, \"medium\" for moderate exploration, or \"very thorough\" for comprehensive analysis across multiple locations and naming conventions.\n- **statusline-setup**: Use this agent to configure the user's Qwen Code status line setting.\n\nWhen using the Agent tool, specify a subagent_type parameter to select which agent type to use.\n\nWhen NOT to use the Agent tool:\n- If you want to read a specific file path, use the read_file tool or the glob tool instead of the agent tool, to find the match more quickly\n- If you are searching for a specific class definition like \"class Foo\", use the grep_search tool instead, to find the match more quickly\n- If you are searching for code within a specific file or set of 2-3 files, use the read_file tool instead of the agent tool, to find the match more quickly\n- Other tasks that are not related to the agent descriptions above\n\n\nUsage notes:\n- Always include a short description (3-5 words) summarizing what the agent will do\n- Launch multiple agents concurrently whenever possible, to maximize performance; to do that, use a single message with multiple tool uses\n- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.\n- Provide clear, detailed prompts so the agent can work autonomously and return exactly the information you need.\n- The agent's outputs should generally be trusted\n- Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent\n- If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first. Use your judgement.\n- If the user specifies that they want you to run agents \"in parallel\", you MUST send a single message with multiple Agent tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.\n\nExample usage:\n\n<example_agent_descriptions>\n\"test-runner\": use this agent after you are done writing code to run tests\n\"greeting-responder\": use this agent to respond to user greetings with a friendly joke\n</example_agent_descriptions>\n\n<example>\nuser: \"Please write a function that checks if a number is prime\"\nassistant: I'm going to use the Write tool to write the following code:\n<code>\nfunction isPrime(n) {\n if (n <= 1) return false\n for (let i = 2; i * i <= n; i++) {\n if (n % i === 0) return false\n }\n return true\n}\n</code>\n<commentary>\nSince a significant piece of code was written and the task was completed, now use the test-runner agent to run the tests\n</commentary>\nassistant: Uses the agent tool to launch the test-runner agent\n</example>\n\n<example>\nuser: \"Hello\"\n<commentary>\nSince the user is greeting, use the greeting-responder agent to respond with a friendly joke\n</commentary>\nassistant: \"I'm going to use the agent tool to launch the greeting-responder agent\"\n</example>\n",
  231. "parameters": {
  232. "type": "object",
  233. "properties": {
  234. "description": {
  235. "type": "string",
  236. "description": "A short (3-5 word) description of the task"
  237. },
  238. "prompt": {
  239. "type": "string",
  240. "description": "The task for the agent to perform"
  241. },
  242. "subagent_type": {
  243. "type": "string",
  244. "description": "The type of specialized agent to use for this task",
  245. "enum": [
  246. "general-purpose",
  247. "Explore",
  248. "statusline-setup"
  249. ]
  250. }
  251. },
  252. "required": [
  253. "description",
  254. "prompt",
  255. "subagent_type"
  256. ],
  257. "additionalProperties": false,
  258. "$schema": "http://json-schema.org/draft-07/schema#"
  259. }
  260. }
  261. },
  262. {
  263. "type": "function",
  264. "function": {
  265. "name": "skill",
  266. "description": "Execute a skill within the main conversation\n\n<skills_instructions>\nWhen users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.\n\nHow to invoke:\n- Use this tool with the skill name only (no arguments)\n- Examples:\n - `skill: \"pdf\"` - invoke the pdf skill\n - `skill: \"xlsx\"` - invoke the xlsx skill\n - `skill: \"ms-office-suite:pdf\"` - invoke using fully qualified name\n\nImportant:\n- When a skill is relevant, you must invoke this tool IMMEDIATELY as your first action\n- NEVER just announce or mention a skill in your text response without actually calling this tool\n- This is a BLOCKING REQUIREMENT: invoke the relevant Skill tool BEFORE generating any other response about the task\n- Only use skills listed in <available_skills> below\n- Do not invoke a skill that is already running\n- Do not use this tool for built-in CLI commands (like /help, /clear, etc.)\n- When executing scripts or loading referenced files, ALWAYS resolve absolute paths from skill's base directory. Examples:\n - `bash scripts/init.sh` -> `bash /path/to/skill/scripts/init.sh`\n - `python scripts/helper.py` -> `python /path/to/skill/scripts/helper.py`\n - `reference.md` -> `/path/to/skill/reference.md`\n</skills_instructions>\n\n<available_skills>\n<skill>\n<name>\nloop\n</name>\n<description>\nCreate a recurring loop that runs a prompt on a schedule. Usage - /loop 5m check the build, /loop check the PR every 30m, /loop run tests (defaults to 10m). /loop list to show jobs, /loop clear to cancel all. (bundled)\n</description>\n<location>\nbundled\n</location>\n</skill>\n<skill>\n<name>\nqc-helper\n</name>\n<description>\nAnswer any question about Qwen Code usage, features, configuration, and troubleshooting by referencing the official user documentation. Also helps users view or modify their settings.json. Invoke with `/qc-helper` followed by a question, e.g. `/qc-helper how do I configure MCP servers?` or `/qc-helper change approval mode to yolo`. (bundled)\n</description>\n<location>\nbundled\n</location>\n</skill>\n<skill>\n<name>\nreview\n</name>\n<description>\nReview changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, or `/review <pr-number> --comment` to post inline comments on the PR. (bundled)\n</description>\n<location>\nbundled\n</location>\n</skill>\n</available_skills>\n",
  267. "parameters": {
  268. "type": "object",
  269. "properties": {
  270. "skill": {
  271. "type": "string",
  272. "description": "The skill name (no arguments). E.g., \"pdf\" or \"xlsx\""
  273. }
  274. },
  275. "required": [
  276. "skill"
  277. ],
  278. "additionalProperties": false,
  279. "$schema": "http://json-schema.org/draft-07/schema#"
  280. }
  281. }
  282. },
  283. {
  284. "type": "function",
  285. "function": {
  286. "name": "list_directory",
  287. "description": "Lists the names of files and subdirectories directly within a specified directory path. Can optionally ignore entries matching provided glob patterns.",
  288. "parameters": {
  289. "properties": {
  290. "path": {
  291. "description": "The absolute path to the directory to list (must be absolute, not relative)",
  292. "type": "string"
  293. },
  294. "ignore": {
  295. "description": "List of glob patterns to ignore",
  296. "items": {
  297. "type": "string"
  298. },
  299. "type": "array"
  300. },
  301. "file_filtering_options": {
  302. "description": "Optional: Whether to respect ignore patterns from .gitignore or .qwenignore",
  303. "type": "object",
  304. "properties": {
  305. "respect_git_ignore": {
  306. "description": "Optional: Whether to respect .gitignore patterns when listing files. Only available in git repositories. Defaults to true.",
  307. "type": "boolean"
  308. },
  309. "respect_qwen_ignore": {
  310. "description": "Optional: Whether to respect .qwenignore patterns when listing files. Defaults to true.",
  311. "type": "boolean"
  312. }
  313. }
  314. }
  315. },
  316. "required": [
  317. "path"
  318. ],
  319. "type": "object"
  320. }
  321. }
  322. },
  323. {
  324. "type": "function",
  325. "function": {
  326. "name": "read_file",
  327. "description": "Reads and returns the content of a specified file. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), and PDF files. For text files, it can read specific line ranges.",
  328. "parameters": {
  329. "properties": {
  330. "file_path": {
  331. "description": "The absolute path to the file to read (e.g., '/home/user/project/file.txt'). Relative paths are not supported. You must provide an absolute path.",
  332. "type": "string"
  333. },
  334. "offset": {
  335. "description": "Optional: For text files, the 0-based line number to start reading from. Requires 'limit' to be set. Use for paginating through large files.",
  336. "type": "number"
  337. },
  338. "limit": {
  339. "description": "Optional: For text files, maximum number of lines to read. Use with 'offset' to paginate through large files. If omitted, reads the entire file (if feasible, up to a default limit).",
  340. "type": "number"
  341. }
  342. },
  343. "required": [
  344. "file_path"
  345. ],
  346. "type": "object"
  347. }
  348. }
  349. },
  350. {
  351. "type": "function",
  352. "function": {
  353. "name": "grep_search",
  354. "description": "A powerful search tool built on ripgrep\n\n Usage:\n - ALWAYS use Grep for search tasks. NEVER invoke `grep` or `rg` as a Bash command. The Grep tool has been optimized for correct permissions and access.\n - Supports full regex syntax (e.g., \"log.*Error\", \"function\\s+\\w+\")\n - Filter files with glob parameter (e.g., \"*.js\", \"**/*.tsx\")\n - Use Agent tool for open-ended searches requiring multiple rounds\n - Pattern syntax: Uses ripgrep (not grep) - special regex characters need escaping (use `interface\\{\\}` to find `interface{}` in Go code)\n",
  355. "parameters": {
  356. "properties": {
  357. "pattern": {
  358. "type": "string",
  359. "description": "The regular expression pattern to search for in file contents"
  360. },
  361. "glob": {
  362. "type": "string",
  363. "description": "Glob pattern to filter files (e.g. \"*.js\", \"*.{ts,tsx}\") - maps to rg --glob"
  364. },
  365. "path": {
  366. "type": "string",
  367. "description": "File or directory to search in (rg PATH). Defaults to current working directory."
  368. },
  369. "limit": {
  370. "type": "number",
  371. "description": "Limit output to first N lines/entries. Optional - shows all matches if not specified."
  372. }
  373. },
  374. "required": [
  375. "pattern"
  376. ],
  377. "type": "object"
  378. }
  379. }
  380. },
  381. {
  382. "type": "function",
  383. "function": {
  384. "name": "glob",
  385. "description": "Fast file pattern matching tool that works with any codebase size\n- Supports glob patterns like \"**/*.js\" or \"src/**/*.ts\"\n- Returns matching file paths sorted by modification time\n- Use this tool when you need to find files by name patterns\n- When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead\n- You have the capability to call multiple tools in a single response. It is always better to speculatively perform multiple searches as a batch that are potentially useful.",
  386. "parameters": {
  387. "properties": {
  388. "pattern": {
  389. "description": "The glob pattern to match files against",
  390. "type": "string"
  391. },
  392. "path": {
  393. "description": "The directory to search in. If not specified, the current working directory will be used. IMPORTANT: Omit this field to use the default directory. DO NOT enter \"undefined\" or \"null\" - simply omit it for the default behavior. Must be a valid directory path if provided.",
  394. "type": "string"
  395. }
  396. },
  397. "required": [
  398. "pattern"
  399. ],
  400. "type": "object"
  401. }
  402. }
  403. },
  404. {
  405. "type": "function",
  406. "function": {
  407. "name": "edit",
  408. "description": "Replaces text within a file. By default, replaces a single occurrence. Set `replace_all` to true when you intend to modify every instance of `old_string`. This tool requires providing significant context around the change to ensure precise targeting. Always use the read_file tool to examine the file's current content before attempting a text replacement.\n\n The user has the ability to modify the `new_string` content. If modified, this will be stated in the response.\n\nExpectation for required parameters:\n1. `file_path` MUST be an absolute path; otherwise an error will be thrown.\n2. `old_string` MUST be the exact literal text to replace (including all whitespace, indentation, newlines, and surrounding code etc.).\n3. `new_string` MUST be the exact literal text to replace `old_string` with (also including all whitespace, indentation, newlines, and surrounding code etc.). Ensure the resulting code is correct and idiomatic.\n4. NEVER escape `old_string` or `new_string`, that would break the exact literal text requirement.\n**Important:** If ANY of the above are not satisfied, the tool will fail. CRITICAL for `old_string`: Must uniquely identify the single instance to change. Include at least 3 lines of context BEFORE and AFTER the target text, matching whitespace and indentation precisely. If this string matches multiple locations, or does not match exactly, the tool will fail.\n**Multiple replacements:** Set `replace_all` to true when you want to replace every occurrence that matches `old_string`.",
  409. "parameters": {
  410. "properties": {
  411. "file_path": {
  412. "description": "The absolute path to the file to modify. Must start with '/'.",
  413. "type": "string"
  414. },
  415. "old_string": {
  416. "description": "The exact literal text to replace, preferably unescaped. For single replacements (default), include at least 3 lines of context BEFORE and AFTER the target text, matching whitespace and indentation precisely. If this string is not the exact literal text (i.e. you escaped it) or does not match exactly, the tool will fail.",
  417. "type": "string"
  418. },
  419. "new_string": {
  420. "description": "The exact literal text to replace `old_string` with, preferably unescaped. Provide the EXACT text. Ensure the resulting code is correct and idiomatic.",
  421. "type": "string"
  422. },
  423. "replace_all": {
  424. "type": "boolean",
  425. "description": "Replace all occurrences of old_string (default false)."
  426. }
  427. },
  428. "required": [
  429. "file_path",
  430. "old_string",
  431. "new_string"
  432. ],
  433. "type": "object"
  434. }
  435. }
  436. },
  437. {
  438. "type": "function",
  439. "function": {
  440. "name": "write_file",
  441. "description": "Writes content to a specified file in the local filesystem.\n\n The user has the ability to modify `content`. If modified, this will be stated in the response.",
  442. "parameters": {
  443. "properties": {
  444. "file_path": {
  445. "description": "The absolute path to the file to write to (e.g., '/home/user/project/file.txt'). Relative paths are not supported.",
  446. "type": "string"
  447. },
  448. "content": {
  449. "description": "The content to write to the file.",
  450. "type": "string"
  451. }
  452. },
  453. "required": [
  454. "file_path",
  455. "content"
  456. ],
  457. "type": "object"
  458. }
  459. }
  460. },
  461. {
  462. "type": "function",
  463. "function": {
  464. "name": "run_shell_command",
  465. "description": "Executes a given shell command (as `bash -c <command>`) in a persistent shell session with optional timeout, ensuring proper handling and security measures.\n\nIMPORTANT: This tool is for terminal operations like git, npm, docker, etc. DO NOT use it for file operations (reading, writing, editing, searching, finding files) - use the specialized tools for this instead.\n\n**Usage notes**:\n- The command argument is required.\n- You can specify an optional timeout in milliseconds (up to 600000ms / 10 minutes). If not specified, commands will timeout after 120000ms (2 minutes).\n- It is very helpful if you write a clear, concise description of what this command does in 5-10 words.\n\n- Avoid using run_shell_command with the `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or when these commands are truly necessary for the task. Instead, always prefer using the dedicated tools for these commands:\n - File search: Use glob (NOT find or ls)\n - Content search: Use grep_search (NOT grep or rg)\n - Read files: Use read_file (NOT cat/head/tail)\n - Edit files: Use edit (NOT sed/awk)\n - Write files: Use write_file (NOT echo >/cat <<EOF)\n - Communication: Output text directly (NOT echo/printf)\n- When issuing multiple commands:\n - If the commands are independent and can run in parallel, make multiple run_shell_command tool calls in a single message. For example, if you need to run \"git status\" and \"git diff\", send a single message with two run_shell_command tool calls in parallel.\n - If the commands depend on each other and must run sequentially, use a single run_shell_command call with '&&' to chain them together (e.g., `git add . && git commit -m \"message\" && git push`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before run_shell_command for git operations, or git add before git commit), run these operations sequentially instead.\n - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail\n - DO NOT use newlines to separate commands (newlines are ok in quoted strings)\n- Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of `cd`. You may use `cd` if the User explicitly requests it.\n <good-example>\n pytest /foo/bar/tests\n </good-example>\n <bad-example>\n cd /foo/bar && pytest tests\n </bad-example>\n\n**Background vs Foreground Execution:**\n- You should decide whether commands should run in background or foreground based on their nature:\n- Use background execution (is_background: true) for:\n - Long-running development servers: `npm run start`, `npm run dev`, `yarn dev`, `bun run start`\n - Build watchers: `npm run watch`, `webpack --watch`\n - Database servers: `mongod`, `mysql`, `redis-server`\n - Web servers: `python -m http.server`, `php -S localhost:8000`\n - Any command expected to run indefinitely until manually stopped\n\n - Command is executed as a subprocess that leads its own process group. Command process group can be terminated as `kill -- -PGID` or signaled as `kill -s SIGNAL -- -PGID`.\n- Use foreground execution (is_background: false) for:\n - One-time commands: `ls`, `cat`, `grep`\n - Build commands: `npm run build`, `make`\n - Installation commands: `npm install`, `pip install`\n - Git operations: `git commit`, `git push`\n - Test runs: `npm test`, `pytest`\n",
  466. "parameters": {
  467. "type": "object",
  468. "properties": {
  469. "command": {
  470. "type": "string",
  471. "description": "Exact bash command to execute as `bash -c <command>`"
  472. },
  473. "is_background": {
  474. "type": "boolean",
  475. "description": "Optional: Whether to run the command in background. If not specified, defaults to false (foreground execution). Explicitly set to true for long-running processes like development servers, watchers, or daemons that should continue running without blocking further commands."
  476. },
  477. "timeout": {
  478. "type": "number",
  479. "description": "Optional timeout in milliseconds (max 600000)"
  480. },
  481. "description": {
  482. "type": "string",
  483. "description": "Brief description of the command for the user. Be specific and concise. Ideally a single sentence. Can be up to 3 sentences for clarity. No line breaks."
  484. },
  485. "directory": {
  486. "type": "string",
  487. "description": "(OPTIONAL) The absolute path of the directory to run the command in. If not provided, the project root directory is used. Must be a directory within the workspace and must already exist."
  488. }
  489. },
  490. "required": [
  491. "command"
  492. ]
  493. }
  494. }
  495. },
  496. {
  497. "type": "function",
  498. "function": {
  499. "name": "save_memory",
  500. "description": "\nSaves a specific piece of information or fact to your long-term memory.\n\nUse this tool:\n\n- When the user explicitly asks you to remember something (e.g., \"Remember that I like pineapple on pizza\", \"Please save this: my cat's name is Whiskers\").\n- When the user states a clear, concise fact about themselves, their preferences, or their environment that seems important for you to retain for future interactions to provide a more personalized and effective assistance.\n\nDo NOT use this tool:\n\n- To remember conversational context that is only relevant for the current session.\n- To save long, complex, or rambling pieces of text. The fact should be relatively short and to the point.\n- If you are unsure whether the information is a fact worth remembering long-term. If in doubt, you can ask the user, \"Should I remember that for you?\"\n\n## Parameters\n\n- `fact` (string, required): The specific fact or piece of information to remember. This should be a clear, self-contained statement. For example, if the user says \"My favorite color is blue\", the fact would be \"My favorite color is blue\".\n- `scope` (string, optional): Where to save the memory:\n - \"global\": Saves to user-level ~/.qwen/QWEN.md (shared across all projects)\n - \"project\": Saves to current project's QWEN.md (project-specific)\n - If not specified, the tool will ask the user where they want to save the memory.\n",
  501. "parameters": {
  502. "type": "object",
  503. "properties": {
  504. "fact": {
  505. "type": "string",
  506. "description": "The specific fact or piece of information to remember. Should be a clear, self-contained statement."
  507. },
  508. "scope": {
  509. "type": "string",
  510. "description": "Where to save the memory: \"global\" saves to user-level ~/.qwen/QWEN.md (shared across all projects), \"project\" saves to current project's QWEN.md (project-specific). If not specified, will prompt user to choose.",
  511. "enum": [
  512. "global",
  513. "project"
  514. ]
  515. }
  516. },
  517. "required": [
  518. "fact"
  519. ]
  520. }
  521. }
  522. },
  523. {
  524. "type": "function",
  525. "function": {
  526. "name": "todo_write",
  527. "description": "\nUse this tool to create and manage a structured task list for your current coding session. This helps you track progress, organize complex tasks, and demonstrate thoroughness to the user.\nIt also helps the user understand the progress of the task and overall progress of their requests.\n\n## When to Use This Tool\nUse this tool proactively in these scenarios:\n\n1. Complex multi-step tasks - When a task requires 3 or more distinct steps or actions\n2. Non-trivial and complex tasks - Tasks that require careful planning or multiple operations\n3. User explicitly requests todo list - When the user directly asks you to use the todo list\n4. User provides multiple tasks - When users provide a list of things to be done (numbered or comma-separated)\n5. After receiving new instructions - Immediately capture user requirements as todos\n6. When you start working on a task - Mark it as in_progress BEFORE beginning work. Ideally you should only have one todo as in_progress at a time\n7. After completing a task - Mark it as completed and add any new follow-up tasks discovered during implementation\n\n## When NOT to Use This Tool\n\nSkip using this tool when:\n1. There is only a single, straightforward task\n2. The task is trivial and tracking it provides no organizational benefit\n3. The task can be completed in less than 3 trivial steps\n4. The task is purely conversational or informational\n\nNOTE that you should not use this tool if there is only one trivial task to do. In this case you are better off just doing the task directly.\n\n## Examples of When to Use the Todo List\n\n<example>\nUser: I want to add a dark mode toggle to the application settings. Make sure you run the tests and build when you're done!\nAssistant: I'll help add a dark mode toggle to your application settings. Let me create a todo list to track this implementation.\n*Creates todo list with the following items:*\n1. Create dark mode toggle component in Settings page\n2. Add dark mode state management (context/store)\n3. Implement CSS-in-JS styles for dark theme\n4. Update existing components to support theme switching\n5. Run tests and build process, addressing any failures or errors that occur\n*Begins working on the first task*\n\n<reasoning>\nThe assistant used the todo list because:\n1. Adding dark mode is a multi-step feature requiring UI, state management, and styling changes\n2. The user explicitly requested tests and build be run afterward\n3. The assistant inferred that tests and build need to pass by adding \"Ensure tests and build succeed\" as the final task\n</reasoning>\n</example>\n\n<example>\nUser: Help me rename the function getCwd to getCurrentWorkingDirectory across my project\nAssistant: Let me first search through your codebase to find all occurrences of 'getCwd'.\n*Uses grep or search tools to locate all instances of getCwd in the codebase*\nAssistant: I've found 15 instances of 'getCwd' across 8 different files. Let me create a todo list to track these changes.\n*Creates todo list with specific items for each file that needs updating*\n\n<reasoning>\nThe assistant used the todo list because:\n1. First, the assistant searched to understand the scope of the task\n2. Upon finding multiple occurrences across different files, it determined this was a complex task with multiple steps\n3. The todo list helps ensure every instance is tracked and updated systematically\n4. This approach prevents missing any occurrences and maintains code consistency\n</reasoning>\n</example>\n\n\n<example>\nUser: I need to implement these features for my e-commerce site: user registration, product catalog, shopping cart, and checkout flow.\nAssistant: I'll help implement these features. First, let's add all the features to the todo list.\n*Creates a todo list breaking down each feature into specific tasks based on the project architecture*\nAssistant: Let's start with user registration. This will involve creating database models, API endpoints, and frontend forms that integrate with your existing authentication system.\n\n<reasoning>\nThe assistant used the todo list because:\n1. The user provided multiple complex features to implement in a comma separated list\n2. The todo list helps organize these large features into manageable tasks\n3. This approach allows for tracking progress across the entire implementation\n</reasoning>\n</example>\n\n<example>\nUser: Can you help optimize my React application? It's rendering slowly and has performance issues.</user>\nAssistant: I'll help optimize your React application. First, let me examine your codebase to identify potential performance bottlenecks.\n*Reviews component structure, render patterns, state management, and data fetching*\nAssistant: After analyzing your codebase, I've identified several performance issues. Let me create a todo list to track our optimization efforts.\n*Creates todo list with items like: 1) Implement memoization for expensive calculations in ProductList, 2) Add virtualization for long lists in Dashboard, 3) Optimize image loading in Gallery component, 4) Fix state update loops in ShoppingCart, 5) Review bundle size and implement code splitting*\nLet's start by implementing memoization for the expensive calculations in your ProductList component.</assistant>\n\n<reasoning>\nThe assistant used the todo list because:\n1. First, the assistant examined the codebase to identify specific performance issues\n2. Based on this analysis, it identified multiple optimization opportunities\n3. Performance optimization is a non-trivial task requiring multiple steps\n4. The todo list helps methodically track improvements across different components\n5. This systematic approach ensures all performance bottlenecks are addressed\n</reasoning>\n</example>\n\n## Examples of When NOT to Use the Todo List\n\n<example>\nUser: How do I print 'Hello World' in Python?\nAssistant: In Python, you can print \"Hello World\" with this simple code:\n\npython\nprint(\"Hello World\")\n\nThis will output the text \"Hello World\" to the console when executed.</assistant>\n\n<reasoning>\nThe assistant did not use the todo list because this is a single, trivial task that can be completed in one step. There's no need to track multiple tasks or steps for such a straightforward request.\n</reasoning>\n</example>\n\n<example>\nUser: What does the git status command do?\nAssistant: The git status command shows the current state of your working directory and staging area. It displays which changes have been staged, which haven't, and which files aren't being tracked by Git. This is a fundamental command for understanding the current state of your repository before making commits.\n\n<reasoning>\nThe assistant did not use the todo list because this is an informational request with no actual coding task to complete. The user is simply asking for an explanation, not for the assistant to perform multiple steps or tasks.\n</reasoning>\n</example>\n\n<example>\nUser: Can you add a comment to the calculateTotal function to explain what it does?\nAssistant: Sure, let me add a comment to the calculateTotal function to explain what it does.\n* Uses the Edit tool to add a comment to the calculateTotal function *\n\n<reasoning>\nThe assistant did not use the todo list because this is a single, straightforward task confined to one location in the code. Adding a comment doesn't require tracking multiple steps or systematic organization.\n</reasoning>\n</example>\n\n<example>\nUser: Run npm install for me and tell me what happens.\nAssistant: I'll run the npm install command for you.\n\n*Executes: npm install*\n\nThe command completed successfully. Here's the output:\n[Output of npm install command]\n\nAll dependencies have been installed according to your package.json file.\n\n<reasoning>\nThe assistant did not use the todo list because this is a single command execution with immediate results. There are no multiple steps to track or organize, making the todo list unnecessary for this straightforward task.\n</reasoning>\n</example>\n\n## Task States and Management\n\n1. **Task States**: Use these states to track progress:\n - pending: Task not yet started\n - in_progress: Currently working on (limit to ONE task at a time)\n - completed: Task finished successfully\n\n2. **Task Management**:\n - Update task status in real-time as you work\n - Mark tasks complete IMMEDIATELY after finishing (don't batch completions)\n - Only have ONE task in_progress at any time\n - Complete current tasks before starting new ones\n - Remove tasks that are no longer relevant from the list entirely\n\n3. **Task Completion Requirements**:\n - ONLY mark a task as completed when you have FULLY accomplished it\n - If you encounter errors, blockers, or cannot finish, keep the task as in_progress\n - When blocked, create a new task describing what needs to be resolved\n - Never mark a task as completed if:\n - Tests are failing\n - Implementation is partial\n - You encountered unresolved errors\n - You couldn't find necessary files or dependencies\n\n4. **Task Breakdown**:\n - Create specific, actionable items\n - Break complex tasks into smaller, manageable steps\n - Use clear, descriptive task names\n\nWhen in doubt, use this tool. Being proactive with task management demonstrates attentiveness and ensures you complete all requirements successfully.\n",
  528. "parameters": {
  529. "type": "object",
  530. "properties": {
  531. "todos": {
  532. "type": "array",
  533. "items": {
  534. "type": "object",
  535. "properties": {
  536. "content": {
  537. "type": "string",
  538. "minLength": 1
  539. },
  540. "status": {
  541. "type": "string",
  542. "enum": [
  543. "pending",
  544. "in_progress",
  545. "completed"
  546. ]
  547. },
  548. "id": {
  549. "type": "string"
  550. }
  551. },
  552. "required": [
  553. "content",
  554. "status",
  555. "id"
  556. ],
  557. "additionalProperties": false
  558. },
  559. "description": "The updated todo list"
  560. }
  561. },
  562. "required": [
  563. "todos"
  564. ],
  565. "$schema": "http://json-schema.org/draft-07/schema#"
  566. }
  567. }
  568. },
  569. {
  570. "type": "function",
  571. "function": {
  572. "name": "ask_user_question",
  573. "description": "Use this tool when you need to ask the user questions during execution. This allows you to:\n1. Gather user preferences or requirements\n2. Clarify ambiguous instructions\n3. Get decisions on implementation choices as you work\n4. Offer choices to the user about what direction to take.\n\nUsage notes:\n- Users will always be able to select \"Other\" to provide custom text input\n- Use multiSelect: true to allow multiple answers to be selected for a question\n- If you recommend a specific option, make that the first option in the list and add \"(Recommended)\" at the end of the label\n\nPlan mode note: In plan mode, use this tool to clarify requirements or choose between approaches BEFORE finalizing your plan. Do NOT use this tool to ask \"Is this plan ready?\" or \"Should I proceed?\" - use ExitPlanMode for plan approval.\n",
  574. "parameters": {
  575. "$schema": "https://json-schema.org/draft/2020-12/schema",
  576. "type": "object",
  577. "properties": {
  578. "questions": {
  579. "description": "Questions to ask the user (1-4 questions)",
  580. "minItems": 1,
  581. "maxItems": 4,
  582. "type": "array",
  583. "items": {
  584. "type": "object",
  585. "properties": {
  586. "question": {
  587. "description": "The complete question to ask the user. Should be clear, specific, and end with a question mark. Example: \"Which library should we use for date formatting?\" If multiSelect is true, phrase it accordingly, e.g. \"Which features do you want to enable?\"",
  588. "type": "string"
  589. },
  590. "header": {
  591. "description": "Very short label displayed as a chip/tag (max 12 chars). Examples: \"Auth method\", \"Library\", \"Approach\".",
  592. "type": "string"
  593. },
  594. "options": {
  595. "description": "The available choices for this question. Must have 2-4 options. Each option should be a distinct, mutually exclusive choice (unless multiSelect is enabled). There should be no 'Other' option, that will be provided automatically.",
  596. "minItems": 2,
  597. "maxItems": 4,
  598. "type": "array",
  599. "items": {
  600. "type": "object",
  601. "properties": {
  602. "label": {
  603. "description": "The display text for this option that the user will see and select. Should be concise (1-5 words) and clearly describe the choice.",
  604. "type": "string"
  605. },
  606. "description": {
  607. "description": "Explanation of what this option means or what will happen if chosen. Useful for providing context about trade-offs or implications.",
  608. "type": "string"
  609. }
  610. },
  611. "required": [
  612. "label",
  613. "description"
  614. ],
  615. "additionalProperties": false
  616. }
  617. },
  618. "multiSelect": {
  619. "description": "Set to true to allow the user to select multiple options instead of just one. Use when choices are not mutually exclusive.",
  620. "default": false,
  621. "type": "boolean"
  622. }
  623. },
  624. "required": [
  625. "question",
  626. "header",
  627. "options",
  628. "multiSelect"
  629. ],
  630. "additionalProperties": false
  631. }
  632. },
  633. "metadata": {
  634. "description": "Optional metadata for tracking and analytics purposes. Not displayed to user.",
  635. "type": "object",
  636. "properties": {
  637. "source": {
  638. "description": "Optional identifier for the source of this question (e.g., \"remember\" for /remember command). Used for analytics tracking.",
  639. "type": "string"
  640. }
  641. },
  642. "additionalProperties": false
  643. }
  644. },
  645. "required": [
  646. "questions"
  647. ],
  648. "additionalProperties": false
  649. }
  650. }
  651. },
  652. {
  653. "type": "function",
  654. "function": {
  655. "name": "exit_plan_mode",
  656. "description": "Use this tool when you are in plan mode and have finished presenting your plan and are ready to code. This will prompt the user to exit plan mode.\n\n## When to Use This Tool\nIMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.\n\n## Before Using This Tool\nEnsure your plan is complete and unambiguous:\n- If you have unresolved questions about requirements or approach, use AskUserQuestion first (in earlier phases)\n- Once your plan is finalized, use THIS tool to request approval\n\n**Important:** Do NOT use AskUserQuestion to ask \"Is this plan okay?\" or \"Should I proceed?\" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.\n\n## Examples\n1. Initial task: \"Search for and understand the implementation of vim mode in the codebase\" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.\n2. Initial task: \"Help me implement yank mode for vim\" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.\n3. Initial task: \"Add a new feature to handle user authentication\" - If unsure about auth method (OAuth, JWT, etc.), use AskUserQuestion first, then use exit plan mode tool after clarifying the approach.\n",
  657. "parameters": {
  658. "type": "object",
  659. "properties": {
  660. "plan": {
  661. "type": "string",
  662. "description": "The plan you came up with, that you want to run by the user for approval. Supports markdown. The plan should be pretty concise."
  663. }
  664. },
  665. "required": [
  666. "plan"
  667. ],
  668. "additionalProperties": false,
  669. "$schema": "http://json-schema.org/draft-07/schema#"
  670. }
  671. }
  672. },
  673. {
  674. "type": "function",
  675. "function": {
  676. "name": "web_fetch",
  677. "description": "Fetches content from a specified URL and processes it using an AI model\n- Takes a URL and a prompt as input\n- Fetches the URL content, converts HTML to markdown\n- Processes the content with the prompt using a small, fast model\n- Returns the model's response about the content\n- Use this tool when you need to retrieve and analyze web content\n\nUsage notes:\n - IMPORTANT: If an MCP-provided web fetch tool is available, prefer using that tool instead of this one, as it may have fewer restrictions. All MCP-provided tools start with \"mcp__\".\n - The URL must be a fully-formed valid URL\n - The prompt should describe what information you want to extract from the page\n - This tool is read-only and does not modify any files\n - Results may be summarized if the content is very large\n - Supports both public and private/localhost URLs using direct fetch",
  678. "parameters": {
  679. "properties": {
  680. "url": {
  681. "description": "The URL to fetch content from",
  682. "type": "string"
  683. },
  684. "prompt": {
  685. "description": "The prompt to run on the fetched content",
  686. "type": "string"
  687. }
  688. },
  689. "required": [
  690. "url",
  691. "prompt"
  692. ],
  693. "type": "object"
  694. }
  695. }
  696. },
  697. {
  698. "type": "function",
  699. "function": {
  700. "name": "mcp__0__run_python",
  701. "description": "Execute Python code in IDA Pro environment. Has access to idc, idaapi, ida_hexrays, ida_kernwin modules.",
  702. "parameters": {
  703. "type": "object",
  704. "properties": {
  705. "code": {
  706. "type": "string",
  707. "description": "Python code to execute in IDA environment"
  708. }
  709. },
  710. "required": [
  711. "code"
  712. ]
  713. }
  714. }
  715. },
  716. {
  717. "type": "function",
  718. "function": {
  719. "name": "mcp__0__get_function_info",
  720. "description": "Get information about the function at current address",
  721. "parameters": {
  722. "type": "object",
  723. "properties": {},
  724. "required": []
  725. }
  726. }
  727. }
  728. ]
  729. },
  730. "response": {
  731. "id": "chatcmpl-74a72a728fbe",
  732. "object": "chat.completion",
  733. "created": 1776290,
  734. "model": "coder-model",
  735. "choices": [
  736. {
  737. "index": 0,
  738. "message": {
  739. "role": "assistant",
  740. "content": "The tool keeps returning the folder structure instead of actual git status output. This might be a system issue. Let me try a different approach and",
  741. "refusal": null
  742. },
  743. "finish_reason": "stop",
  744. "logprobs": null
  745. }
  746. ],
  747. "usage": {
  748. "prompt_tokens": 0,
  749. "completion_tokens": 0,
  750. "total_tokens": 0
  751. }
  752. },
  753. "error": null,
  754. "system": {
  755. "hostname": "sta-x360",
  756. "platform": "linux",
  757. "release": "6.8.0-107-generic",
  758. "nodeVersion": "v20.20.2"
  759. }
  760. }
Advertisement
Comments
  • User was banned
  • User was banned
  • User was banned
  • User was banned
Add Comment
Please, Sign In to add comment