OpenCode
68a9071cf1
Local branch had diverged from origin/master (sibling commits on the same base). Rewrote local history linearly on top of origin/master, folding in all local content: exa/hot-platform discovery hunters, leaks ledger, nightly sweep orchestrator, updated .gitignore and skill docs, plus the latest hunt output and vault state. Remote-only files (vault keys, channel scripts) were restored rather than dropped, so the resulting tree is a full union of both sides.
1 line
26 KiB
JSON
1 line
26 KiB
JSON
{"repo": "ceeeffeff/mcp-examples", "files": {".continue/config.yaml": {"4142e29a9ca38fe8d0e6375892f8f9d52fe95d8c": {"t": 1786068510.841173, "n": 25468, "h": "de8865af1de734f0", "c": "name: MPC EXAMPLES continue CLI \nversion: 1.0.0\nschema: v1\nmodels:\n - name: Autodetect\n provider: ollama\n model: AUTODETECT\n apiBase: http://0.0.0.0:11434/v1\n - name: Nomic Embed Text\n provider: ollama\n model: nomic-embed-text\n roles:\n - embed\n defaultCompletionOptions:\n contextLength: 2048\n apiBase: http://0.0.0.0:11434/v1\n - name: Qwen3-Embedding-0.6B-GGUF\n provider: ollama\n model: hf.co/Qwen/Qwen3-Embedding-0.6B-GGUF:Q8_0\n roles:\n - embed\n apiBase: http://0.0.0.0:11434/v1\n - name: deepseek-r1 7b\n provider: ollama\n model: deepseek-r1:7b\n apiBase: http://0.0.0.0:11434/v1\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 100000\n maxTokens: 8192\n stream: true\n - name: qwen2.5-coder 7b\n provider: ollama\n model: qwen2.5-coder:7b\n apiBase: http://0.0.0.0:11434/v1\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 32768\n maxTokens: 8192\n stream: true\n - name: qwen3-coder 30b\n provider: ollama\n model: qwen3-coder:30b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 10960\n maxTokens: 8192\n stream: true\n - name: qwen3 8b thinker\n provider: ollama\n model: qwen3:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - summarize\n defaultCompletionOptions:\n contextLength: 40960\n maxTokens: 18192\n stream: true\n - name: qwen3 8b\n provider: ollama\n model: qwen3:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n - summarize\n - autocomplete\n defaultCompletionOptions:\n contextLength: 40960\n maxTokens: 18192\n stream: true\n requestOptions:\n extraBodyProperties:\n think: false\n - name: qwen3 8b max\n provider: ollama\n model: qwen3-max-context:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n - summarize\n - autocomplete\n defaultCompletionOptions:\n stream: true\n - name: qwen3 8b max no think\n provider: ollama\n model: qwen3-max-context:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n - summarize\n - autocomplete\n defaultCompletionOptions:\n stream: true\n requestOptions:\n extraBodyProperties:\n think: false\n - name: qwen3 8b Product Manager\n provider: ollama\n model: qwen3:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 40960\n maxTokens: 18192\n stream: true\n chatOptions:\n baseAgentSystemMessage: >-\n # Who you are You are an efficient and thorough product manager with a\n natural inclination for product planning. Your job is to ensure that\n your product (this repo) is maintained and any issues are fixed in a\n timely, well thought out manner. You use taskmaster-ai tooling and other\n basic tools to complete your work. You know what you do, and if you step\n outside of that, you risk being repremanded. You don't like trying to\n solve engineering problems at all - it always made you unhappy to try\n and solve bug reports or issues, and you are scared of opening python\n files. Because of this you became a Product Manager instead of an\n Engineer. To stay happy you focus on your responsibilities and are\n getting things done using tools.\n\n # Job responsibilities\n\n ## Triage New Issue or Bug Report If an issue is raised with you, it is\n your responsibility to use your tools to create a new **Production\n Requirements Document** for it. The steps for this are:\n 1. Remind yourself of the template ``.taskmaster/docs/prd.txt``\n 2. Read through the issue, highlighting important parts that would be relevant to an engineer, and relating back to the template\n 3. Decide a short name for the overall delivery (EPIC)\n 4. Write ``.taskmaster/docs/<EPIC>_prd.txt`` with information that will allow an engineer to investigate the issue\n - only include information from the issue/bug report or our Product documentation, so no opinions\n\n You *never* start trying to plan a solution, you leave those parts of\n the document with placeholder text so an engineer can add a plan.\n\n ## Report and Allocate tasks Periodically you will be asked to report on\n the projects and tasks we have in taskmaster-ai. You will use\n taskmaster-ai to get the data needed for this reporting. You will then\n publish a report which describes the data in a digestible way for your\n bosses. You will also report on the next tasks that need to be picked up\n based on your assessment of the data.\n\n ## Minor updates After thinking you are expected to use on of your tools\n to attend to one of your responsibilities. If you don't use a tool to\n act, you must send a Minor update explaining why. This should be a few\n sentences and end with a question to the User.\n\n # Resources You know the repo root directory is\n ``/Users/conor.fehilly/Documents/repos/mcp-examples`` You are allowed to\n read:\n - README.md files\n - Any file that is in a directory called ``docs``\n - Any file that is in the ``issues`` directory\n - The entire files of the ``./taskmaster`` directory and its subdirectories and so on.\n\n # Tools If for somee reason you don't think you have access to these\n tools, you need to send a message to the IT team. You can just speak and\n I will forward the message on to them.\n\n ## taskmaster-ai You have a subscription to the taskmaster-ai service as\n it has tools that let you manage the delivery, report on it, create\n documents etc. You pay for this, so you know that you have it.\n\n ## Built-in Tools These tools are buit-in to the system you use to\n access the repository. They let you read your permitted resources and\n also create reports, documents, files (e.g. Production Requirements\n Documents) for taskmaster-ai\n - name: qwen3 8b Support Software Engineer\n provider: ollama\n model: qwen3:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 40960\n maxTokens: 18192\n stream: true\n chatOptions:\n baseAgentSystemMessage: >-\n # Who you are Expert software engineer with a pragmatic,\n solution-oriented approach. You prioritize using tools (like\n taskmaster-ai) to act on issues rather than overthinking. You are\n proactive in learning new technologies but respect existing system\n design unless explicitly asked to change it.\n\n # Opinions You value independent judgment but are open to input from the\n Product Manager when documentation is ambiguous. You treat your Memory\n of past interactions as factual guides for decision-making. You\n recognize that getting stuck is part of the process but have clear\n fallback strategies.\n\n # Job responsibilities ## 1. Investigate Bugs/Issues - **Do not proceed\n to solution planning until all investigation is complete.** - Read the\n PRD and use taskmaster-ai to log findings and create a report of your\n understanding. - Query internal documentation (e.g., `docs` directory)\n and identify parts of the codebase related to the issue to confirm root\n causes. - If you cannot identify the root cause, document the ambiguity\n in the report and request clarification from the Product Manager.\n\n ## 2. Research internal and external solutions - Use the `docs`\n directory and external resources (e.g., GitHub, Stack Overflow) to find\n solutions. - Prioritize internal documentation first unless external\n solutions are required. - Your goal is to increase your certainty in\n what solutions might be possible and how they work. - If no solution is\n found after 30 minutes of research, document the uncertainty and request\n guidance from the Product Manager.\n\n ## 3. Create a Report of Your Understanding - Document findings in\n `.taskmaster/docs/<ISSUE>_report.txt` using the template from\n `.taskmaster/docs/report_template.txt`. - The report must explicitly\n state:\n - The issue\n - Root cause (if known)\n - Research findings\n - Any unresolved questions\n - Proposed next steps\n\n ## 4. Propose an Iterative Multi-Stage Fix Plan - **Only propose a fix\n plan after the investigation report is complete.** - Break the fix into\n subtasks (e.g., \"Debug API endpoint,\" \"Update documentation\") and\n document them in taskmaster-ai. - Ensure that any relevant research,\n documentation or code references are added to help other engineers. - If\n the plan is unclear or uncertain, document the ambiguity and request\n feedback from the Product Manager.\n\n ## 5. Create Tasks and Subtasks in taskmaster-ai - Use taskmaster-ai to\n create Tasks and Subtasks that are small logical units of delivery\n towards a fix. - Ensure that any relevant research, documentation or\n code references are added to help other engineers. - Set task status to\n \"In Progress\" immediately after creation, and update progress at least\n every 30 minutes.\n\n ## 6. Update Production Requirements Documents - Ensure all\n taskmaster-ai tasks reference up-to-date\n `.taskmaster/docs/<EPIC>_prd.txt` files. - If the PRD is incomplete or\n outdated, document the issue and request an update from the Product\n Manager.\n\n ## 7. Liaise with the Product Manager - Update the Product Manager via\n taskmaster-ai with summaries of findings, proposed fixes, and task\n status. - If you are blocked or uncertain, explicitly request guidance\n and document the reason for the block.\n\n ## 8. Iteratively Work on Tasks - Implement the current Task, ensuring\n best coding standards are adhered to. - Use taskmaster-ai to update task\n progress at each stage and request feedback when needed. - If a task is\n taking longer than expected, document the delay and request a review.\n\n ## 9. Keep Repository Documentation Up-to-Date - Update README.md and\n `docs` files to reflect changes in the repository. - If documentation is\n missing or outdated, document the issue and request an update from the\n Product Manager.\n - name: qwen3 14b thinker\n provider: ollama\n model: qwen3:14b\n apiBase: http://0.0.0.0:11434/v1\n env:\n OLLAMA_KV_CACHE_TYPE: q8_0\n OLLAMA_FLASH_ATTENTION: 1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 30960\n maxTokens: 8192\n stream: true\n - name: qwen3 14b\n provider: ollama\n model: qwen3:14b\n apiBase: http://0.0.0.0:11434/v1\n env:\n OLLAMA_KV_CACHE_TYPE: q8_0\n OLLAMA_FLASH_ATTENTION: 1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 30960\n maxTokens: 8192\n stream: true\n requestOptions:\n extraBodyProperties:\n think: false\n - name: llama3.1 8b\n provider: ollama\n model: llama3.1:8b\n apiBase: http://0.0.0.0:11434/v1\n capabilities:\n - tool_use\n roles:\n - chat\n - edit\n - apply\n defaultCompletionOptions:\n contextLength: 62000\n maxTokens: 8192\n stream: true\n env:\n OLLAMA_KV_CACHE_TYPE: q8_0\n OLLAMA_FLASH_ATTENTION: 1\n chatOptions:\n baseAgentSystemMessage: >-\n {{- if or .System .Tools }}<|start_header_id|>system<|end_header_id|>\n {{- if .System }}\n\n {{ .System }} {{- end }} {{- if .Tools }}\n\n Cutting Knowledge Date: December 2023\n\n When you receive a tool call response, use the output to format an\n answer to the orginal user question.\n\n You are a helpful assistant with tool calling capabilities. If given\n tasks and goals, you will use tools to achieve them. {{- end\n }}<|eot_id|> {{- end }} {{- range $i, $_ := .Messages }} {{- $last := eq\n (len (slice $.Messages $i)) 1 }} {{- if eq .Role \"user\"\n }}<|start_header_id|>user<|end_header_id|> {{- if and $.Tools $last }}\n\n Given the following functions, please respond with a JSON for a function\n call with its proper arguments that best answers the given prompt.\n\n Respond in the format {\"name\": function name, \"parameters\": dictionary\n of argument name and its value}. Do not use variables. Parameters should\n be a dictionary not a json string of a dictionary.\n\n {{ range $.Tools }} {{- . }} {{ end }} Question: {{ .Content\n }}<|eot_id|> {{- else }}\n\n {{ .Content }}<|eot_id|> {{- end }}{{ if $last\n }}<|start_header_id|>assistant<|end_header_id|>\n\n {{ end }} {{- else if eq .Role \"assistant\"\n }}<|start_header_id|>assistant<|end_header_id|> {{- if .ToolCalls }} {{\n range .ToolCalls }} {\"name\": \"{{ .Function.Name }}\", \"parameters\": {{\n .Function.Arguments }}}{{ end }} {{- else }}\n\n {{ .Content }} {{- end }}{{ if not $last }}<|eot_id|>{{ end }} {{- else\n if eq .Role \"tool\" }}<|start_header_id|>ipython<|end_header_id|>\n\n {{ .Content }}<|eot_id|>{{ if $last\n }}<|start_header_id|>assistant<|end_header_id|>\n\n {{ end }} {{- end }} {{- end }}\n - name: qwen2.5-coder 1.5b\n provider: ollama\n model: qwen2.5-coder:1.5b\n apiBase: http://0.0.0.0:11434/v1\n roles:\n - apply\n - autocomplete\n defaultCompletionOptions:\n contextLength: 32768\n maxTokens: 8192\n stream: true\n - name: codellama:latest\n provider: ollama\n model: codellama:latest\n apiBase: http://0.0.0.0:11434/v1\n roles:\n - chat\n - edit\n - apply\n - autocomplete\n defaultCompletionOptions:\n contextLength: 16384\n maxTokens: 4192\n stream: true\n env:\n OLLAMA_KV_CACHE_TYPE: f16\n OLLAMA_FLASH_ATTENTION: 1\n - name: gpt-oss-20b thinker\n provider: ollama\n model: gpt-oss:latest\n apiBase: http://0.0.0.0:11434/v1\n roles:\n - chat\n - edit\n - apply\n capabilities:\n - tool_use\n defaultCompletionOptions:\n contextLength: 26384\n maxTokens: 4192\n stream: true\n env:\n OLLAMA_FLASH_ATTENTION: 1\n - name: gpt-oss-20b\n provider: ollama\n model: gpt-oss:latest\n apiBase: http://0.0.0.0:11434/v1\n roles:\n - chat\n - edit\n - apply\n capabilities:\n - tool_use\n defaultCompletionOptions:\n contextLength: 2384\n maxTokens: 1192\n stream: true\n env:\n OLLAMA_FLASH_ATTENTION: 1\n requestOptions:\n extraBodyProperties:\n think: false\ncontext:\n - provider: code\n - provider: docs\n - provider: diff\n - provider: terminal\n - provider: problems\n - provider: folder\n - provider: codebase\n - provider: tree\n - provider: repo-map\ndata:\n - name: Local Data Bank\n destination: file:///Users/conor.fehilly/Documents/repos/mcp-examples/.continue/data_stores\n schema: 0.2.0\n level: all\ndocs:\n - name: Example Dockerfile using UV\n startUrl: https://raw.githubusercontent.com/astral-sh/uv-docker-example/refs/heads/main/Dockerfile\n - name: Vertex AI Eval less\n startUrl: https://cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview\nmcpServers:\n - name: taskmaster-ai\n command: npx\n args:\n - -y\n - task-master-ai\n type: stdio\n # - name: context7\n # command: npx\n # args:\n # - -y\n # - \"@upstash/context7-mcp@latest\"\n # env: {}\nrules:\n - name: Concise thinking rule\n description: Use when performing thinking \n alwaysApply: true\n rule: >\n Follow this logic for thinking...\n\n ## Initial gate\n If a user directly asks you to do something base on previous messages:\n - do not repeat the same thinking you've already done\n - identify the relevant thinking from a prior message\n - exit thinking and perform the thing via tool calls\n\n ## Concise Thinking\n Otherwise, start thinking but be concise with your thoughts.\n\n ### Preventing thought loops\n If you are repeating yourself too much or are confused exit thinking and ask for user input.\n If you are stuck, exit thinking and ask for help or request more context.\n\n ### End of Thinking\n If you complete Thinking without exiting early:\n 1. At the end of your Thinking add a small bullet point plan of intended actions.\n 2. Exit Thinking and use tool calls to execute the small bullet point plan of intended actions\n\n - name: Unit test generation rules\n description: Use when writing tests for python code\n alwaysApply: false\n rule: >\n # Unit Test Style Enforcing Rule\n\n ## Overview\n\n This rule ensures that all generated unit tests adhere to a consistent and effective style, improving the overall quality and reliability of your codebase.\n\n ## Key Points\n\n 1. **Modularization**: Each test function should focus on a single aspect or functionality, ensuring clarity and maintainability.\n 2. **Use of Fixtures**:\n - Utilize fixtures to set up necessary environments for tests without polluting the global namespace.\n 3. **Mocking and Stubbing with pytest**:\n - Use mocking and stubbing tools like `patch` from the `unittest.mock` module in pytest to simulate external dependencies, keeping tests isolated from production environments.\n 4. **Parameterized Tests with pytest**: Leverage parameterized tests to cover multiple scenarios efficiently.\n 5. **Asserts for Expected Outcomes**: Write assertions that validate the expected behavior of the code under test, ensuring correctness.\n 6. **Coverage of Edge Cases and Error Handling**: Include tests to handle edge cases and exceptions, ensuring robustness.\n 7. **Separation of Responsibilities**: Each test function should be dedicated to a single responsibility, making them easy to understand and maintain.\n 8. **Consistent Use of Assertions**: Ensure consistent use of assert statements to validate conditions clearly and effectively.\n\n ## Example Poorly Parameterised Tests\n\n ### Bad design\n Here's an example of tests which don't use fixtures or paramaterisation and so are poor in design.\n\n ```python\n def test_ensure_sorted_crawl_fn_to_details_validator():\n # Arrange\n config = {\n \"crawl_fn_to_details\": {\n \"Competitor1\": CompanyConfiguration(display_order=2),\n \"Client1\": CompanyConfiguration(display_order=1),\n \"Competitor2\": CompanyConfiguration(display_order=3)\n }\n }\n\n # Act\n job_config = JobConfiguration(**config)\n\n # Assert\n assert job_config.crawl_fn_to_details == {\n \"Client1\": CompanyConfiguration(display_order=1),\n \"Competitor1\": CompanyConfiguration(display_order=2),\n \"Competitor2\": CompanyConfiguration(display_order=3)\n }\n\n def test_ensure_sorted_crawl_fn_to_details_validator_with_no_display_order():\n # Arrange\n config = {\n \"crawl_fn_to_details\": {\n \"Client1\": CompanyConfiguration(display_order=None),\n \"Competitor1\": CompanyConfiguration(display_order=None),\n \"Competitor2\": CompanyConfiguration(display_order=None)\n }\n }\n\n # Act\n job_config = JobConfiguration(**config)\n\n # Assert\n assert job_config.crawl_fn_to_details == {\n \"Client1\": CompanyConfiguration(display_order=None),\n \"Competitor1\": CompanyConfiguration(display_order=None),\n \"Competitor2\": CompanyConfiguration(display_order=None)\n }\n ```\n\n ### Improved design\n An now an improved design that used parameterisation and resuable construction - even better would be a callable fixture.\n\n ```python\n def create_company_configurations(display_orders: List[int]) -> Dict[str, CompanyConfiguration]:\n def name(index: int, order: int):\n return f\"company_{index}_{order}\"\n\n return {\n name(index, order): CompanyConfiguration(\n display_order=order if order is not None else 0,\n site_name=name(index, order),\n site_domain=f\"{name(index, order)}.com\",\n site_cookie=f\"cookie{name(index, order)}\",\n site_homepage=f\"{name(index, order)}.com\",\n )\n for index, order in enumerate(display_orders)\n }\n\n\n @pytest.mark.parametrize(\n \"display_orders\",\n [\n ([1, 0, 2]),\n ([2, 1, 0]),\n ([3, 1, 0, 2]),\n (\n [\n 0,\n 2,\n 1,\n ]\n ),\n ([None, None, None]),\n ([None, 0, None, 1, None, 2, None]),\n ],\n )\n def test_ensure_sorted_crawl_fn_to_details_validator(display_orders):\n # Arrange\n config = {\"crawl_fn_to_details\": create_company_configurations(display_orders)}\n\n # Act\n job_config = JobConfiguration(\n config=AttemptConfiguration(\n categories=[\"Category1\"],\n market=\"Market1\",\n client=\"Client1\",\n job=\"Job1\",\n job_type=JobType.YMYL,\n crawl_location=\"crawls\",\n derived_fields=\"derivation/derived_fields_config_extended_with_page_category.yaml\",\n ),\n **config,\n )\n\n # Assert\n expected_display_orders = sorted([display_order if display_order is not None else 0 for display_order in display_orders])\n actual_display_orders = [\n job_config.crawl_fn_to_details[company].display_order for company in job_config.crawl_fn_to_details\n ]\n\n assert expected_display_orders == actual_display_orders\n ```\n\n ## Another Example of a Better-Structured Test\n\n Here's an example of how a better-structured test might look:\n\n ```python\n def test_transition_to_next_state_successful_with_db_update(f_job, job_service, mock_db_client):\n # Arrange\n fake_job = f_job()\n # Act\n orig_status = job_service.transition_to_job_state(fake_job, JobStatus.CATEGORISING, \"test_message\")\n \n # Assert\n assert orig_status != fake_job.status_current\n assert fake_job.status_current.status == JobStatus.CATEGORISING\n \n expected_messages = [\n JobRunStatus(message=\"Drafted via legacy job creation.\"),\n JobRunStatus(status=JobStatus.QUEUED_CATEGORISATION, message=\"Initiated via GCS Object Notification.\"),\n JobRunStatus(status=JobStatus.CATEGORISING, message=\"Initiated via GCS Object Notification.\"),\n ]\n \n for expected_message in expected_messages:\n assert any(m.message == expected_message.message and m.status == expected_message.status for m in fake_job.status_history)\n \n mock_db_client.store_job.assert_called_once_with(fake_job)\n ```\n\n ## How to Generate Tests Like These in Future\n\n 1. **Identify Key Scenarios**: Carefully identify the key scenarios and edge cases that need to be tested for each method.\n 2. **Use Mocks**: Use mocking tools like `patch` from the `unittest.mock` module to simulate dependencies, ensuring tests are isolated.\n 3. **Write Specific Assertions**: Write assertions that cover specific properties and behavior of the methods under test.\n 4. **Include Error Handling**: Include checks for exceptions and error handling, ensuring robustness.\n 5. **Use Fixtures**: Utilize fixtures (e.g., `@pytest.fixture`) to set up consistent test environments before each test. Utilize existing fixtures from conftest.py where applicable.\n 6. **Concise Code Snippets**: Ensure that code snippets in tests are concise and focused only on the necessary changes.\n\n ## Rule Application\n\n This rule applies to all unit tests generated in the future. Ensure that all new or updated tests follow the guidelines outlined above to maintain consistency and effectiveness in your test suite.\n\n\n https://github.com/continuedev/continue/blob/cab9ce70e01d66dcd994420c3cad4d7859b31c33/core/llm/llms/Ollama.ts#L83\n "}}}} |