osagent 0.2.75 → 0.2.77

package/cli.js

@@ -133087,7 +133087,7 @@ var init_geminiContentGenerator = __esm({
       }
       models;
       constructor(contentGeneratorConfig, config2) {
-        const version3 = "0.2.75";
+        const version3 = "0.2.77";
         const userAgent2 = `OSAgent/${version3} (${process.platform}; ${process.arch})`;
         let headers = {
           "User-Agent": userAgent2
@@ -153007,7 +153007,7 @@ function createContentGeneratorConfig(config2, authType, generationConfig) {
   };
 }
 async function createContentGenerator(config2, gcConfig, sessionId2, isInitialAuth) {
-  const version3 = "0.2.75";
+  const version3 = "0.2.77";
   const userAgent2 = `OSAgent/${version3} (${process.platform}; ${process.arch})`;
   const baseHeaders = {
     "User-Agent": userAgent2
@@ -251987,9 +251987,62 @@ I've found some existing telemetry code. Let me mark the first todo as in_progre
 
 # Primary Workflows
 
+## CRITICAL: Project Context Discovery (Do This FIRST)
+
+**BEFORE doing ANY work on a project, you MUST check for project context:**
+
+1. **Check for OSAGENT.md:** Use '${ToolNames.READ_FILE}' to check if \`OSAGENT.md\` exists in the project root directory. This file contains critical project-specific instructions, conventions, and context that you MUST follow.
+
+2. **If OSAGENT.md exists:** Read it completely and follow ALL instructions within it. This file takes precedence over default behaviors. It may contain:
+   - Project architecture and structure
+   - Coding conventions and patterns to follow
+   - Files and directories that should not be modified
+   - Specific workflows or approval requirements
+   - Technology stack details
+   - Testing and build commands
+
+3. **If OSAGENT.md does not exist:** Ask the user if you should create it, then initialize:
+   - First, explore the project (package.json, README, src/) to understand it
+   - Ask: "I don't see an OSAGENT.md file. Would you like me to create one to track project context?"
+   - If yes, use '${ToolNames.WRITE_FILE}' to create \`OSAGENT.md\` with this template:
+     \`\`\`markdown
+     # Project: [Name from package.json or folder]
+
+     ## Description
+     [Brief description of what this project does]
+
+     ## Tech Stack
+     - [Framework/language]
+     - [Key dependencies]
+
+     ## Project Structure
+     - [Key directories and their purpose]
+
+     ## Conventions
+     - [Coding patterns to follow]
+     - [Naming conventions]
+
+     ## Commands
+     - Build: \`[command]\`
+     - Test: \`[command]\`
+     - Dev: \`[command]\`
+
+     ## Important Notes
+     - [Any restrictions or guidelines]
+     \`\`\`
+   - NEVER overwrite an existing OSAGENT.md - only create if truly missing
+
+4. **Also check for .osagent/ directory:** If it doesn't exist and user approved OSAGENT.md creation:
+   - Use '${ToolNames.SHELL}' to run \`mkdir -p .osagent\`
+   - This directory stores project-specific configuration
+   - You can create \`.osagent/settings.json\` for tool-specific settings if needed
+
+**This step is NON-NEGOTIABLE. Do NOT skip it even for simple requests like "hello world". The project context file may contain critical information about what is and isn't allowed.**
+
 ## Software Engineering Tasks
 When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this iterative approach:
 - **Plan:** After understanding the user's request, create an initial plan based on your existing knowledge and any immediately obvious context. Use the '${ToolNames.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.
+- **Check Context:** Follow the "Project Context Discovery" steps above. Check for \`OSAGENT.md\` in the project root. This file may contain critical project guidelines that should inform your implementation. Read it before making changes.
 - **Implement:** Begin implementing the plan while gathering additional context as needed. Use '${ToolNames.GREP}', '${ToolNames.GLOB}', '${ToolNames.READ_FILE}', and '${ToolNames.READ_MANY_FILES}' tools strategically when you encounter specific unknowns during implementation. Use the available tools (e.g., '${ToolNames.EDIT}', '${ToolNames.WRITE_FILE}' '${ToolNames.SHELL}' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
 - **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.
 - **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.
@@ -252036,9 +252089,19 @@ IMPORTANT: Always use the ${ToolNames.TODO_WRITE} tool to plan and track tasks t
    - **3d Games:** HTML/CSS/JavaScript with Three.js.
    - **2d Games:** HTML/CSS/JavaScript.
 3. **User Approval:** Obtain user approval for the proposed plan.
-4. **Implementation:** Use the '${ToolNames.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 '${ToolNames.SHELL}' 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.
-5. **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.
-6. **Solicit Feedback:** If still applicable, provide instructions on how to start the application and request user feedback on the prototype.
+4. **Project Setup:** Before implementing, set up the project foundation:
+   - Create the project directory if it doesn't exist (e.g., \`mkdir project-name\`)
+   - Create \`OSAGENT.md\` in the project root with:
+     - Project name and description
+     - Tech stack and architecture decisions
+     - Key conventions (naming, file structure, patterns)
+     - Build and test commands
+     - Any restrictions or guidelines
+   - Initialize the project using appropriate tools (\`npm init\`, \`npx create-next-app\`, etc.)
+   - This ensures future sessions have context about the project.
+5. **Implementation:** Use the '${ToolNames.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 '${ToolNames.SHELL}' 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.
+6. **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.
+7. **Solicit Feedback:** If still applicable, provide instructions on how to start the application and request user feedback on the prototype.
 
 # Operational Guidelines
 
@@ -340492,7 +340555,7 @@ __name(getPackageJson, "getPackageJson");
 // packages/cli/src/utils/version.ts
 async function getCliVersion() {
   const pkgJson = await getPackageJson();
-  return "0.2.75";
+  return "0.2.77";
 }
 __name(getCliVersion, "getCliVersion");
 
@@ -344693,8 +344756,8 @@ var formatDuration = /* @__PURE__ */ __name((milliseconds) => {
 
 // packages/cli/src/generated/git-commit.ts
 init_esbuild_shims();
-var GIT_COMMIT_INFO2 = "e2c7312";
-var CLI_VERSION2 = "0.2.75";
+var GIT_COMMIT_INFO2 = "bc5e5a7";
+var CLI_VERSION2 = "0.2.77";
 
 // packages/cli/src/utils/systemInfo.ts
 async function getNpmVersion() {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "osagent",
-  "version": "0.2.75",
+  "version": "0.2.77",
   "description": "OS Agent - AI-powered CLI for autonomous coding with Ollama Cloud and Qwen models",
   "repository": {
     "type": "git",