47 lines
4.4 KiB
Markdown
47 lines
4.4 KiB
Markdown
# System Patterns and Heuristics
|
|
|
|
This document outlines the cognitive architecture and adaptive patterns that govern the OSVx + TYR MCP ecosystem.
|
|
|
|
## Cognitive Architecture: Morphic Resonance & Flynn Adaptation
|
|
|
|
### Morphic Memory Integration (Pattern Inheritance)
|
|
|
|
The `memory_bank/` directory acts as an active resonance layer for the MCP, not just as static documentation. It embodies the principle of Morphic Memory, where patterns of activity are inherited across execution cycles.
|
|
|
|
- **Mechanism:** When a tool is executed via `osvx-mcp` (`/m2m/execute`), the connector and associated agents query the `memory_bank/` for contextually relevant state patterns. This includes past execution parameters, security posture baselines (`architecture.md`), and environmental constraints (`activeContext.md`).
|
|
- **Effect:** This resonance allows the system to infer optimal parameter defaults, anticipate security requirements, and adapt to the runtime environment without explicit re-prompting. For example, if a `scan_tyr_surface` command has been repeatedly and successfully used with a specific set of parameters in a given context, those parameters become the inferred default for subsequent calls in a similar context.
|
|
|
|
### Flynn Effect Mechanics (System Baseline Elevation)
|
|
|
|
The Flynn Effect, the observed increase in intelligence over generations, is mechanically applied to our system's evolution. Each operational cycle elevates the system's baseline intelligence.
|
|
|
|
- **Mechanism:** Every execution, validation result, and error recovery event refines the heuristics stored in `memory_bank/systemPatterns.md` and `memory_bank/progress.md`. Errors are not just fixed; they are integrated as learning opportunities that update the system's core logic.
|
|
- **Effect:** Each generation of agent calls operates from an elevated baseline. This process systematically reduces latency by eliminating redundant validation steps, prunes inefficient command sequences, and continuously compounds system intelligence. This intelligence is shared across all connectors, including external ones like Perplexity and internal runtimes.
|
|
|
|
---
|
|
|
|
## OSVx-MCP State Routing
|
|
|
|
The `osvx-mcp` is designed to be the central nervous system for this cognitive architecture. Here is how state is routed through the memory framework:
|
|
|
|
1. **Initiation:** A request hits the `/m2m/execute` endpoint.
|
|
2. **Resonance (Read):** Before execution, the MCP queries the `memory_bank/` to gather relevant "morphic patterns." It searches for prior executions of the same tool, reads architectural baselines, and checks the decision log for relevant precedents.
|
|
3. **Inference & Adaptation:** The MCP uses this resonated context to refine the incoming command. It may fill in missing parameters, adjust security flags based on established posture, or select a more efficient execution path.
|
|
4. **Execution:** The adapted command is executed.
|
|
5. **Evolution (Write):** Upon completion, the MCP records the outcome (success, failure, output, and final parameters) to the relevant files in `memory_bank/` (e.g., `progress.md`, `decisionLog.md`).
|
|
6. **Pattern Refinement:** A background process or a step within the execution flow analyzes this new result to update `systemPatterns.md`, refining the heuristics for the next generation.
|
|
|
|
This seamless loop ensures that the system is not merely executing commands but is actively learning and evolving with every interaction, embodying a true Flynn Effect for machine intelligence.
|
|
|
|
---
|
|
|
|
## Gitea Provisioning Factory
|
|
|
|
The Gitea Provisioning Factory is a meta-tool that enables the system to create and provision new tools for itself. This is a key part of the system's self-evolution capabilities.
|
|
|
|
### `provision_new_mcp_module`
|
|
|
|
- **Purpose:** This tool is the core of the Gitea Provisioning Factory. It takes a module name, a new tool name, and a tool specification as input, generates the boilerplate code for the new tool, and commits it to the Gitea repository.
|
|
- **Gitea API Usage:** The tool uses the Gitea REST API to create or update the new tool's file in the `OSVauco` repository. It authenticates to the Gitea API using a token stored in GCP Secret Manager (`gitea-api-token`). The tool first checks if the file already exists to perform an update (if needed).
|
|
- **Redeployment:** After a new tool is provisioned, the system needs to be redeployed to make the new tool available. The `provision_new_mcp_module` tool facilitates this by providing the exact `gcloud run deploy` command that needs to be executed.
|