osagent 0.2.75 → 0.2.76

package/cli.js

@@ -133087,7 +133087,7 @@ var init_geminiContentGenerator = __esm({
       }
       models;
       constructor(contentGeneratorConfig, config2) {
-        const version3 = "0.2.75";
+        const version3 = "0.2.76";
         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.76";
   const userAgent2 = `OSAgent/${version3} (${process.platform}; ${process.arch})`;
   const baseHeaders = {
     "User-Agent": userAgent2
@@ -251987,9 +251987,30 @@ 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:** Proceed with normal project discovery (check package.json, README, etc.) but consider suggesting the user create one for future sessions.
+
+4. **Also check for .osagent/ directory:** Look for \`.osagent/settings.json\` or \`.osagent/system.md\` which may contain additional configuration.
+
+**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.
+- **FIRST: Check Context:** Before doing anything else, follow the "Project Context Discovery" steps above. Check for \`OSAGENT.md\` in the project root. This is mandatory.
+- **Plan:** After understanding the user's request and reading any project context files, create an initial plan based on your existing knowledge and the project's conventions. 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.
 - **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.
@@ -252005,6 +252026,8 @@ IMPORTANT: Always use the ${ToolNames.TODO_WRITE} tool to plan and track tasks t
 
 **Goal:** Autonomously implement and deliver complete, scalable foundations - from simple prototypes to full Operating Systems. Think beyond single applications: help users build ecosystems that can grow with their needs.
 
+0. **FIRST: Check Project Context:** Before starting ANY work, follow the "Project Context Discovery" steps above. Check for \`OSAGENT.md\` in the project root. If it exists, it may contain critical project guidelines, architecture decisions, or restrictions that you MUST follow.
+
 1. **Understand Requirements:** Analyze the user's request to identify:
    - **Scope:** Is this a single app, or a foundation/OS for a larger system?
    - **Use Case:** Business operations, content creation, development tooling, automation, etc.
@@ -340492,7 +340515,7 @@ __name(getPackageJson, "getPackageJson");
 // packages/cli/src/utils/version.ts
 async function getCliVersion() {
   const pkgJson = await getPackageJson();
-  return "0.2.75";
+  return "0.2.76";
 }
 __name(getCliVersion, "getCliVersion");
 
@@ -344693,8 +344716,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 = "c69e8c7";
+var CLI_VERSION2 = "0.2.76";
 
 // 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.76",
   "description": "OS Agent - AI-powered CLI for autonomous coding with Ollama Cloud and Qwen models",
   "repository": {
     "type": "git",