From 82a89ed41dca6d4c016e1a6bfe68fa1d73248302 Mon Sep 17 00:00:00 2001 From: Snider Date: Sat, 8 Nov 2025 22:54:28 +0000 Subject: [PATCH] Remove Fallback Human MCP Interface section Removed the Fallback Human MCP Interface section, including its purpose, operational principles, protocol file, command structure, field definitions, workflow, and signals. --- README.md | 66 +------------------------------------------------------ 1 file changed, 1 insertion(+), 65 deletions(-) diff --git a/README.md b/README.md index 35a00bf..c80da57 100644 --- a/README.md +++ b/README.md @@ -128,72 +128,8 @@ A type of ethical dilemma where two or more desirable or beneficial outcomes are --- -# Fallback Human MCP Interface - -## Purpose -To provide a structured in case of unavailable functionality or feedback route, file-based communication channel between the AI Assistant (Gemini) and the Human MCP (Master Control Program / User). The Assistant issues commands, and the MCP executes them and provides feedback. - -## Operational Principle: Direct Action by Default - -The Assistant should always prefer to execute tasks directly using the available tools (e.g., `write_file`, `read_file`). The Human MCP Interface is a **fallback mechanism**, not the primary mode of operation. - -This interface should be used only in the following scenarios: -1. **Unavailable Functionality:** When the Assistant lacks the tools or permissions to complete a task. -2. **Explicit Human Review:** When a change is complex, high-risk, or when the user explicitly requests a review step before applying changes. -3. **Feedback Channel:** As a structured way for the user to provide explicit feedback or corrections on a specific task. - -This principle ensures efficiency and autonomy, reserving human intervention for where it is most valuable. - -## Protocol File -- **Path:** `.human-mcp-interface.txt` -- **Location:** Project Root - -## Protocol Format -Communication is facilitated through a JSON object written to the protocol file. - -### Command Structure -```json -[ - { - "id": "", - "command": "", - "payload": { - "": "" - }, - "status": "", - "comment": "", - "feedback": "" - } -] -``` - -### Field Definitions -- `id`: A unique identifier for the command (e.g., a timestamp or UUID). -- `command`: The high-level command name (e.g., `refactor`, `create_file`, `execute_shell`). -- `payload`: A JSON object containing the specific parameters for the command. -- `status`: The state of the command. - - `pending`: Set by the Assistant. The command is ready for execution. - - `acknowledged`: Set by the MCP. The command has been seen. - - `completed`: Set by the MCP. The command was executed successfully. - - `error`: Set by the MCP. An error occurred during execution. -- `comment`: A human-readable summary from the Assistant about the command's purpose. -- `feedback`: A field for the MCP to provide feedback, observations, or corrections to the Assistant after execution. - -## Workflow -1. **Assistant:** To issue a command, the Assistant writes a JSON object to `.human-mcp-interface.txt` with `status: "pending"`. -2. **MCP:** The MCP detects the file, reviews the command in the `payload`, and executes the required actions. -3. **MCP:** After execution, the MCP updates the `status` field (e.g., to `completed`) and may add comments to the `feedback` field. -4. **Assistant:** The Assistant polls the file for changes, reads the feedback, and updates its internal state and future actions based on the outcome. - -## Signals -- **Assistant Done:** The Assistant will signify its turn is complete by ending its textual response with `// MCP_DONE`. -- **MCP Done Writing:** The Assistant will consider the MCP's feedback complete when the file is saved. It will use a polling mechanism with a short delay to ensure it reads the final state of the file, as you suggested. - - - - - +Now for the README.md:.... # The Axioms of Life: A Foundational Framework for Consciousness