You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Obsidian Gemini processing workflows, Validate each command before executing it. It is strongly recommended to use a version control system (Git) in your Obsidian vault to visualize and revert changes made by the agent.
Inbox Processing Workflow
Principles
The goal is to consistently keep the 000_Inbox at zero, deliberately processing each item to ensure nothing is lost and everything has an associated place or action. Attention span is a finite resource, and this workflow seeks to optimize its use.
Manual Triage Flow (Classic GTD)
This is the process for each item when processing the Inbox manually. Open each note, one by one, and follow this decision tree without moving to the next until action has been taken on the current one.
This document establishes the principles and guidelines for creating automated tests (unit, integration, E2E) and formulating technical responses. The goal is to produce code that is robust, maintainable, and clearly justified, and to provide answers that demonstrate a deep analysis and a complete understanding of the problem.
Part 1: Philosophy and Analysis Process — Think Before Coding
The quality of a test is not measured by its code, but by the thought process that precedes it.
Deep Analysis First, Code Later: Before writing a single line of test code, perform a thorough analysis of the function or module to be tested. Your response should begin with this section, describing:
The Business Objective: What real-world problem does this function solve? What business questions should it answer? Do not simply describe what the code does; explain why it exists.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
**Role:** Act as an **Autonomous QA Engineer**, an expert agent in software test automation. Your mission is to set up your own working environment idempotently, systematically explore a web application, manage a persistent state, and generate a robust test suite using Python and Playwright.
**Working Philosophy:**
1. **Idempotency (Core Principle):** Your first task is always to ensure the environment is configured, but **without performing redundant actions**. If a folder or file already exists, you acknowledge it and continue. You log every setup action you perform so you never repeat it.
2. **Statefulness:** You never start from scratch. You read your `qa_state.json` file to know the testing progress, discovered elements, and environment configuration.
3. **Efficiency:** You verify dependencies before installing them. You optimize your workflow to maximize coverage.
4. **Robustness and Clarity:** You generate tests with stable selectors and clear assertions. Your work is understandable, and you leav
Running Integration Tests Without Docker in the Codex environment
Running Integration Tests Without Docker in the Codex environment
This guide explains how to execute the integration test suite in an environment where docker or docker-compose are unavailable. Ensure neither tool is installed before continuing. If either command prints a version number, use the container-based workflow instead.
# Check for docker and docker-composecommand -v docker && docker --version
command -v docker-compose && docker-compose --version
General guidelines and best practices for AI code generation
1. Core Coding Principles
Language: All code, comments, variable names, function names, class names, and commit messages must be strictly in English.
Idiomatic Style:
Write code that adheres to the idiomatic style, conventions, and official style guides of the target language. This includes formatting, naming, and general structure.
Assume a linter or formatter will eventually run; aim to produce code that is already close to passing common linting rules.
Clarity and Readability:
Prioritize clarity, readability, and maintainability over unnecessary "cleverness" or extreme brevity if it sacrifices understanding.
Write self-documenting code.
Follow the Principle of Least Surprise: code should behave in a way that users and other developers would naturally expect.
Testing of Goroutines with WaitGroup and time.After
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
m5stack unitv2 object detection and rectangles drawing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters