Universal Agent Law & Governance
Relevant source files
The following files were used as context for generating this wiki page:
Universal Agent Law & Governance defines the inviolable engineering conduct and portable core standards for all AI agents and human users interacting with the FLEXT Platform. It establishes a zero-tolerance baseline for technical debt, mandates strict adherence to the Single Source of Truth (SSOT), and enforces specific operational protocols for multi-agent coordination within a shared working tree.
These laws are designed to ensure consistency across diverse project types and sessions, preventing the introduction of workarounds, dead code, or unverified results. The governance model centers on "fixing forward," restricted typing, and rigorous validation before any work is considered complete.
Sources: AGENTS.md:5-15, README.md:23-28
Core Engineering Conduct
The "Universal Agent Law" represents a portable core of engineering conduct. It applies to all AI agents (e.g., Claude, Cursor, GitHub Copilot) and users, where explicit user instructions serve as the only override.
Strict Operational Principles
The framework enforces a "Zero-Tolerance / Strict-Total" policy regarding code quality and system integrity.
- Root Cause Resolution: Agents must always fix the root cause of an issue rather than applying workarounds or compatibility wrappers.
- Superseeded Code: Replacement code must result in the immediate removal of the superseded code to prevent "dead code."
- Fail Loud: If essential configuration, contracts, or identity sources are missing, the system must fail immediately rather than using stubs or defaults.
- Fix-Forward-Only: In multi-agent environments, reverting shared work via
git resetorgit restoreis forbidden to prevent destroying in-flight work. Agents must accept the current state and apply fixes on top of it.
Sources: AGENTS.md:17-43
Prohibited Bypasses
The following actions are strictly forbidden to maintain governance:
- Suppression directives (e.g.,
# type: ignore,eslint-disable). - Escape-hatch typing (e.g.,
Any, unchecked casts) without one-line justifications. TODOorFIXMEcomments in production-bound code.- Bypassing blocked operations via subshell wrapping (
bash -c), absolute-path swaps, oreval.
Sources: AGENTS.md:45-53, AGENTS.md:76-85
Governance Hierarchy and Multi-Agent Coordination
Governance is maintained through a combination of engineering laws and coordination mechanisms that allow multiple agents to operate within the same repository without conflict.
Task Coordination Flow
Agents coordinate via a committed task board (e.g., .agents/coordination/tasks.md). This ensures that ownership is clear and work is not duplicated or overwritten.
Figure 1: The standard flow for agent task coordination and landing work.
Sources: AGENTS.md:99-105, AGENTS.md:112-119
Universal Engineering Principles
The governance model mandates adherence to several high-level architectural standards:
| Principle | Description | Source |
|---|---|---|
| SSOT | Single Source of Truth; fail loud if absent. | AGENTS.md:90-91 |
| SOLID | Standard object-oriented design principles (SRP, OCP, LSP, ISP, DIP). | AGENTS.md:92-94 |
| YAGNI | "You Ain't Gonna Need It"; no speculative parameters or dead branches. | AGENTS.md:95-96 |
| DI / DIP | Dependency Injection and Inversion; no hidden globals. | AGENTS.md:97-98 |
Validation and Evidence Requirements
Under Agent Law, a task is not "Done" until the complete chain is validated with objective evidence.
Validation Protocol
- Execution Plan: The agent must execute the agreed plan exactly. Any deviation requires explicit user confirmation.
- Evidence: "Done" requires providing the command, the exit code, and the relevant output line. Partial or assumed results are considered a violation of Rule 5.
- Security Hooks: If a command is blocked by a security hook or sandbox, the agent must stop, diagnose, and provide the exact command for the user to run manually.
Sources: AGENTS.md:58-74, AGENTS.md:76-80
Git Landing and Fast-Forwarding
After validation, work must be landed immediately.
Figure 2: The process for landing verified work into the repository.
Sources: AGENTS.md:107-110, AGENTS.md:121-124
Data Models for Governance Enforcement
The FlextPluginModels and FlextPluginUtilities provide the programmatic structure to enforce these laws during plugin execution and discovery.
Plugin Lifecycle Governance
The Entity class within models.py manages the state and business rule validation for plugins, ensuring they adhere to semantic versioning and naming patterns before activation.
| Field | Validation Rule | Source |
|---|---|---|
name | Pattern: ^[a-zA-Z][a-zA-Z0-9_-]*$ | models.py:53-59, utilities.py:38 |
plugin_version | Semantic Format (X.Y.Z) | models.py:64-67, models.py:91-100 |
is_enabled | Boolean toggle for lifecycle control | models.py:86, test_domain_entities.py:55-70 |
Security Validation
Utilities are provided to scan for dangerous code patterns, enforcing Rule 7 (Blocked-Operation Protocol) and Rule 9 (Engineering Principles).
# From src/flext_plugin/utilities.py:165-177
dangerous_patterns = [
"exec(",
"eval(",
"__import__",
"subprocess",
"os.system",
]
for pattern in dangerous_patterns:
if pattern in content:
return r[None].fail(f"Plugin contains potentially dangerous code: {pattern}")
Sources: src/flext_plugin/utilities.py:165-177
Summary of Governance Protocols
The Universal Agent Law & Governance system ensures that all contributions to the FLEXT Platform, whether by human or AI, maintain a zero-debt baseline. By mandating SSOT, fix-forward strategies, and rigorous evidence-based validation, the system prevents the degradation of the codebase in complex, multi-agent environments. All plugins must pass strict business rule validation and security scans as defined in the domain models and utilities before they are integrated into the platform.
Sources: AGENTS.md:17-25, src/flext_plugin/models.py:202-225, README.md:11-15