# Cortivex Mesh Coordination > Enhanced mesh coordination with MeshResolver nodes for conflict detection, resolution strategies, and multi-agent file ownership - Skill: `ahmedraoofuddin/cortivex-mesh-coordination` (Agent Skill) - Install (CLI): `npx skillmds@latest add ahmedraoofuddin/cortivex-mesh-coordination` - Raw SKILL.md: https://api.skillmd.com/api/skills/ahmedraoofuddin/cortivex-mesh-coordination/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: AhmedRaoofuddin (https://skillmd.com/u/ahmedraoofuddin) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ahmedraoofuddin/cortivex-mesh-coordination --- # Cortivex Mesh Coordination (Enhanced) This skill extends the base cortivex-mesh protocol with MeshResolver node capabilities, automated conflict detection, and resolution strategies adapted from SWARM's coordination patterns. While cortivex-mesh defines the file ownership protocol that every agent must follow, this skill adds the orchestration layer that detects, prevents, and resolves conflicts across the agent pool. ## Overview In multi-agent pipelines, file conflicts are inevitable. Two agents may need the same file, an agent may hold a claim too long, or a complex refactor may touch files that another agent is reviewing. The MeshResolver node sits alongside the SwarmCoordinator and actively manages these situations: - **Detects** potential conflicts before they occur by analyzing task scopes - **Prevents** conflicts by pre-allocating file ownership based on task assignments - **Resolves** conflicts using configurable strategies when they do occur - **Detects deadlocks** when two agents are each waiting for files held by the other ## When to Use - Pipelines with 3+ agents that may modify overlapping files - Refactoring or migration pipelines that touch many files across the codebase - When agents have long-running tasks and file claims may expire before completion - Pipelines where conflict-related failures have occurred in previous runs - Any orchestrated pipeline where you want proactive conflict management rather than reactive error handling You do NOT need a MeshResolver for: - Pipelines where agents work on strictly separate file sets - Read-only analysis pipelines (no file modifications) - Single-agent pipelines ## How It Works ### Conflict Detection The MeshResolver continuously monitors the mesh state and detects conflicts in three categories: **1. Direct Conflicts** -- Two agents attempt to claim the same file simultaneously. ``` Agent A claims src/auth/login.ts for "auto-fixing" Agent B claims src/auth/login.ts for "refactoring" --> MeshResolver detects: direct conflict on src/auth/login.ts ``` **2. Scope Overlaps** -- Two agents' task scopes cover the same directory or module, creating a high probability of future conflicts. ``` Agent A assigned to "refactor src/auth/ module" Agent B assigned to "add input validation to src/auth/ endpoints" --> MeshResolver detects: scope overlap on src/auth/ ``` **3. Deadlocks** -- Two or more agents are each waiting for files held by the other, creating a circular wait. ``` Agent A holds src/auth/login.ts, waiting for src/auth/session.ts Agent B holds src/auth/session.ts, waiting for src/auth/login.ts --> MeshResolver detects: deadlock between Agent A and Agent B ``` ### Resolution Strategies The MeshResolver supports five resolution strategies, configured per-pipeline or per-conflict: | Strategy | Behavior | Best For | |----------|----------|----------| | `priority` | Higher-priority task wins; lower-priority agent releases its claim | Tasks with clear priority differences | | `first-claim` | The agent that claimed first keeps the file; the other waits | Fair ordering; equal-priority tasks | | `preempt` | The coordinator forcibly releases one agent's claim | Time-critical situations | | `partition` | The MeshResolver splits the file scope so each agent works on a subset | Large refactors touching many files | | `serialize` | One agent completes fully before the other begins on the contested files | When parallel work on the same files is unsafe | ### Deadlock Resolution When a deadlock is detected, the MeshResolver: 1. Identifies the cycle of waiting agents 2. Selects the agent with the lowest-priority task as the "victim" 3. Forcibly releases the victim's claim 4. Requeues the victim's task with status `ready` 5. Broadcasts a `deadlock_resolved` event to all agents 6. Logs the deadlock for post-run analysis ### Pre-Allocation Before agents begin work, the MeshResolver can analyze all task assignments and pre-allocate file ownership to prevent conflicts entirely: ``` cortivex_mesh_resolver({ action: "pre_allocate", tasks: [ { task_id: "task-1", agent_id: "agent-1", files: ["src/auth/login.ts", "src/auth/session.ts"] }, { task_id: "task-2", agent_id: "agent-2", files: ["src/api/routes.ts", "src/api/middleware.ts"] }, { task_id: "task-3", agent_id: "agent-3", files: ["src/auth/session.ts", "src/models/user.ts"] } ] }) ``` Response: ```json { "status": "conflicts_detected", "conflicts": [ { "file": "src/auth/session.ts", "agents": ["agent-1", "agent-3"], "tasks": ["task-1", "task-3"] } ], "resolution": { "strategy": "serialize", "order": ["task-1", "task-3"], "reason": "task-1 has higher priority (8) than task-3 (6)" }, "allocation": { "agent-1": ["src/auth/login.ts", "src/auth/session.ts"], "agent-2": ["src/api/routes.ts", "src/api/middleware.ts"], "agent-3": ["src/models/user.ts"] }, "deferred": { "agent-3": { "files": ["src/auth/session.ts"], "available_after": "task-1 completes" } } } ``` ## Pipeline Configuration ### Adding a MeshResolver to an Orchestrated Pipeline ```yaml name: conflict-aware-refactor version: "1.0" description: Multi-agent refactor with proactive conflict resolution nodes: - id: coordinator type: SwarmCoordinator config: pool_size: 4 runtime: auto task_strategy: priority-queue - id: resolver type: MeshResolver depends_on: [coordinator] config: strategy: priority deadlock_detection: true deadlock_check_interval_seconds: 10 pre_allocate: true stale_claim_timeout_seconds: 300 max_wait_seconds: 60 on_conflict: resolve on_deadlock: release_lowest log_conflicts: true - id: monitor type: AgentMonitor depends_on: [coordinator] config: auto_recovery: true - id: analyze type: ArchitectAnalyzer depends_on: [resolver] config: target_path: src/ managed_by: coordinator - id: refactor_auth type: RefactorAgent depends_on: [analyze] config: target_path: src/auth/ managed_by: coordinator mesh_aware: true - id: refactor_api type: RefactorAgent depends_on: [analyze] config: target_path: src/api/ managed_by: coordinator mesh_aware: true - id: refactor_models type: RefactorAgent depends_on: [analyze] config: target_path: src/models/ managed_by: coordinator mesh_aware: true - id: test_run type: TestRunner depends_on: [refactor_auth, refactor_api, refactor_models] config: test_command: npm test coverage_threshold: 80 ``` ### MeshResolver with Partition Strategy For large-scale migrations where many agents need to touch many files: ```yaml name: large-migration version: "1.0" description: TypeScript migration with file partitioning nodes: - id: coordinator type: SwarmCoordinator config: pool_size: 5 runtime: auto - id: resolver type: MeshResolver depends_on: [coordinator] config: strategy: partition partition_method: directory pre_allocate: true deadlock_detection: true - id: analyze type: ArchitectAnalyzer depends_on: [resolver] config: target_path: src/ managed_by: coordinator - id: migrate type: TypeMigrator depends_on: [analyze] config: source_dir: src/ managed_by: coordinator mesh_aware: true batch_size: 10 - id: test type: TestRunner depends_on: [migrate] config: test_command: npx tsc --noEmit && npm test ``` With `partition` strategy, the MeshResolver divides `src/` into non-overlapping directory partitions and assigns each to a different agent instance, preventing any possibility of file conflicts. ## Conflict Event Flow When a conflict occurs during execution, the following sequence plays out: ``` 1. Agent B calls cortivex_mesh({ action: "claim", files: ["src/auth/login.ts"] }) 2. Mesh returns { status: "denied", owner: "agent-A" } 3. Agent B calls cortivex_mesh({ action: "report_conflict", ... }) 4. MeshResolver receives the conflict report 5. MeshResolver checks the configured strategy: - If "priority": compare task priorities of Agent A and Agent B - If "first-claim": Agent A keeps the file; Agent B waits - If "preempt": coordinator decides which agent to interrupt 6. MeshResolver executes the resolution: - Forcibly releases claims if needed - Requeues affected tasks if needed - Notifies agents of the resolution 7. Agent B retries the claim (or receives alternative assignment) ``` ## MeshResolver Node Reference ```yaml - id: resolver type: MeshResolver config: strategy: priority # priority | first-claim | preempt | partition | serialize deadlock_detection: true # enable circular-wait detection deadlock_check_interval_seconds: 10 # how often to check for deadlocks pre_allocate: true # analyze tasks and pre-assign files before execution partition_method: directory # directory | file-list | module (used with partition strategy) stale_claim_timeout_seconds: 300 # force-release claims older than this max_wait_seconds: 60 # max time an agent waits before escalating on_conflict: resolve # resolve | report | halt on_deadlock: release_lowest # release_lowest | release_newest | halt log_conflicts: true # record all conflicts for post-run analysis conflict_report_on_complete: true # include conflict summary in pipeline results ``` ## Monitoring Conflicts ### During Execution ``` cortivex_mesh_resolver({ action: "status", run_id: "ctx-a1b2c3" }) ``` Response: ```json { "active_conflicts": 1, "resolved_conflicts": 3, "deadlocks_detected": 0, "stale_claims_released": 1, "current_conflicts": [ { "file": "src/auth/session.ts", "agents": ["agent-worker-2", "agent-worker-4"], "strategy_applied": "priority", "status": "resolving", "waiting_agent": "agent-worker-4" } ], "allocation_map": { "agent-worker-1": ["src/api/routes.ts", "src/api/middleware.ts"], "agent-worker-2": ["src/auth/login.ts", "src/auth/session.ts"], "agent-worker-3": ["src/models/user.ts", "src/models/session.ts"], "agent-worker-4": ["src/utils/validator.ts"] } } ``` ### Post-Run Conflict Report After the pipeline completes, the MeshResolver produces a conflict summary: ``` Mesh Coordination Report ======================== Total conflicts: 4 Resolved automatically: 4 Deadlocks: 0 Stale claims released: 1 Conflict History: 1. src/auth/session.ts agent-2 vs agent-4 -> resolved by priority (agent-2 won) 2. src/models/user.ts agent-3 vs agent-1 -> resolved by first-claim (agent-3 won) 3. src/utils/helpers.ts agent-1 vs agent-2 -> resolved by priority (agent-1 won) 4. src/auth/login.ts stale claim by agent-2 (expired) -> auto-released Recommendations: - src/auth/ had 2 conflicts; consider partitioning this directory in future runs - agent-4 was blocked 3 times; assign it to a separate module scope ``` ## Quick Reference | Operation | MCP Tool | Description | |-----------|----------|-------------| | Pre-allocate files | `cortivex_mesh_resolver({ action: "pre_allocate", tasks })` | Assign file ownership before execution | | Check resolver status | `cortivex_mesh_resolver({ action: "status", run_id })` | View active conflicts and allocations | | Force resolve conflict | `cortivex_mesh_resolver({ action: "force_resolve", file, winner })` | Manually resolve a stuck conflict | | Release stale claims | `cortivex_mesh_resolver({ action: "release_stale" })` | Free expired claims across all agents | | Detect deadlocks | `cortivex_mesh_resolver({ action: "check_deadlocks" })` | Run deadlock detection on demand | | View conflict history | `cortivex_mesh_resolver({ action: "history", run_id })` | Full log of conflicts and resolutions | | Change strategy | `cortivex_mesh_resolver({ action: "set_strategy", strategy })` | Switch resolution strategy mid-run | | View allocation map | `cortivex_mesh_resolver({ action: "allocation_map" })` | See which agent owns which files | ## Best Practices 1. **Use pre-allocation** for pipelines where task scopes are known in advance. Preventing conflicts is cheaper than resolving them. 2. **Choose the right strategy** -- Use `priority` when tasks have clear importance rankings. Use `partition` for large-scale migrations. Use `serialize` when file-level atomicity is required. 3. **Enable deadlock detection** in any pipeline with 3+ agents that may need overlapping files. 4. **Set stale claim timeouts** to prevent abandoned claims from blocking other agents indefinitely. 5. **Review the conflict report** after each run. Recurring conflicts on the same files suggest the pipeline should partition those directories. 6. **Combine with AgentMonitor** -- Dead agents leave orphaned claims. The AgentMonitor detects agent death, and the MeshResolver releases the dead agent's claims. 7. **Keep claims short** -- Agents should claim files, do their work, and release immediately. Long-held claims increase conflict probability. 8. **Use mesh_aware: true** on modification nodes so they automatically follow the check-claim-release protocol from the base cortivex-mesh skill. ## Reasoning Protocol Before configuring a MeshResolver, reason through: 1. **Will agents actually have overlapping file scopes?** If each agent works on a completely separate directory, you do not need a MeshResolver. Save the overhead. 2. **Which resolution strategy fits the workload?** Use `priority` when tasks have clear importance rankings. Use `partition` for migrations. Use `first-claim` when tasks are equal priority. Use `serialize` only when file-level atomicity is critical. 3. **Should I pre-allocate or resolve on-the-fly?** Pre-allocation prevents conflicts entirely but requires knowing all task scopes in advance. On-the-fly resolution handles dynamic workloads where scopes emerge during execution. 4. **What is the acceptable wait time?** Configure `max_wait_seconds` based on your pipeline's time budget. Short pipelines need aggressive resolution; long-running pipelines can afford to wait. 5. **How many agents are involved?** 2-3 agents rarely need a MeshResolver. 4+ agents with overlapping scopes benefit significantly from proactive coordination. ## Anti-Patterns | Anti-Pattern | Consequence | Correct Approach | |-------------|------------|-----------------| | MeshResolver on a read-only pipeline | Unnecessary overhead; analysis agents do not need file claims | Only use MeshResolver when agents modify files | | `strategy: preempt` as default | Forcibly interrupting agents causes wasted work | Use `priority` or `first-claim` by default; reserve `preempt` for time-critical emergencies | | Disabling deadlock detection | Deadlocked agents hang indefinitely, blocking the pipeline | Always enable for pipelines with 3+ modifying agents | | No `stale_claim_timeout_seconds` | Dead agents' claims never expire, blocking files permanently | Always set a stale claim timeout | | `partition` strategy on tiny codebases | Partitioning 10 files across 5 agents creates 2-file partitions with no benefit | Partition only when file count significantly exceeds agent count | | Ignoring the conflict report | Recurring patterns go unaddressed | Review the post-run conflict report and adjust pipeline scopes to reduce future conflicts | ## Grounding Rules - **Unsure which strategy to use:** Default to `priority`. It handles most scenarios well and degrades gracefully when priorities are equal (falls back to first-claim behavior). - **Too many conflicts in a single directory:** This signals that the directory should be treated as a single unit of work. Assign it to one agent instead of splitting across multiple agents. - **Deadlock detected but cannot identify the cycle:** Use `cortivex_mesh_resolver({ action: "check_deadlocks" })` to get the full cycle. The agent with the lowest-priority task should be the release victim. - **Agent needs a file held by a higher-priority agent:** Wait. Do not escalate unless the wait exceeds `max_wait_seconds`. Higher-priority work should complete first. ## Advanced Capabilities ### Multi-Strategy Conflict Resolution The MeshResolver can evaluate conflicts against multiple strategies simultaneously and select the optimal resolution. Use `cortivex_conflict_resolve` to request a multi-strategy evaluation. ```json { "tool": "cortivex_conflict_resolve", "request": { "action": "evaluate", "conflict_id": "cfl-8x92ka", "file": "src/auth/session.ts", "agents": ["agent-worker-2", "agent-worker-5"], "strategies": ["priority", "partition", "serialize"] } } ``` The resolver scores each strategy and returns a ranked recommendation: ```json { "tool": "cortivex_conflict_resolve", "response": { "conflict_id": "cfl-8x92ka", "recommended_strategy": "serialize", "rankings": [ { "strategy": "serialize", "score": 0.92, "reason": "Sequential adds minimal overhead" }, { "strategy": "priority", "score": 0.85, "reason": "Clear priority gap" }, { "strategy": "partition", "score": 0.41, "reason": "Single file; cannot partition" } ], "applied": "serialize", "execution_order": ["agent-worker-5", "agent-worker-2"] } } ``` ### Distributed Transaction Coordination For pipelines where multiple file modifications must succeed or fail as a unit, define transaction boundaries in your pipeline YAML. ```yaml resolver: type: MeshResolver config: transactions: enabled: true groups: - name: auth-refactor files: [src/auth/login.ts, src/auth/session.ts, src/auth/middleware.ts] atomicity: all-or-nothing rollback_on_failure: true - name: api-update files: [src/api/routes.ts, src/api/handlers.ts] atomicity: best-effort isolation_level: read-committed max_concurrent_transactions: 3 ``` With `all-or-nothing` atomicity, the MeshResolver locks all files in the group before any agent begins. If any agent fails, all changes are rolled back. ### Deadlock Detection & Auto-Recovery The MeshResolver uses a wait-for graph to detect circular dependencies. Configure detection policy to control frequency, victim selection, and recovery. ```json { "deadlock_policy": { "detection": { "enabled": true, "algorithm": "wait-for-graph", "check_interval_ms": 5000 }, "victim_selection": { "strategy": "lowest-priority", "fallback": "youngest-task", "preserve_agents_with_commits": true }, "recovery": { "auto_recover": true, "max_recovery_attempts": 3, "backoff_base_ms": 1000, "on_max_attempts_exceeded": "halt_pipeline" } } } ``` When `preserve_agents_with_commits` is enabled, the victim selector avoids releasing agents that have already committed partial work. The exponential backoff prevents rapid re-deadlocking after recovery. ### Coordination Protocol Selection Use `cortivex_coordination_configure` to switch coordination protocols at runtime. Supported protocols: `pessimistic-locking`, `optimistic-concurrency`, and `hybrid`. ```json { "tool": "cortivex_coordination_configure", "request": { "action": "set_protocol", "run_id": "ctx-d4e5f6", "protocol": "optimistic-concurrency", "params": { "conflict_check": "on-commit", "retry_on_conflict": true, "max_retries": 5 } } } ``` ```json { "tool": "cortivex_coordination_configure", "response": { "run_id": "ctx-d4e5f6", "protocol": "optimistic-concurrency", "previous_protocol": "pessimistic-locking", "status": "applied", "warnings": ["3 agents hold pessimistic locks; converted to version stamps on next cycle"] } } ``` ### Failover & Graceful Degradation Patterns When the MeshResolver encounters failures or agents become unresponsive, failover strategies keep the pipeline running. Define failover behavior with the following schema. ```json { "failover": { "resolver_unavailable": { "strategy": "fallback-to-local", "local_strategy": "first-claim", "max_local_duration_seconds": 300 }, "agent_unresponsive": { "detection_timeout_seconds": 30, "action": "release-and-reassign", "preserve_partial_work": true }, "degradation_levels": [ { "level": 1, "trigger": "single_agent_failure", "response": "reassign_tasks" }, { "level": 2, "trigger": "resolver_partial_failure", "response": "switch_to_local_resolution" }, { "level": 3, "trigger": "multiple_agent_failures", "response": "pause_and_consolidate" } ] } } ``` When `fallback-to-local` activates, each agent uses local conflict resolution until the MeshResolver recovers. At degradation level 3, the coordinator pauses all agents, consolidates remaining work into fewer agents, and resumes with a simplified allocation map. ## Security Hardening (OWASP AST10 Aligned) This section defines security controls for Cortivex mesh coordination operations, aligned with the OWASP Agentic Security Top 10 risk framework. Each subsection references the specific AST risk ID it mitigates. ### AST06: Force-Release Protection The `preempt` resolution strategy forcibly releases an agent's file claims, which can cause data loss if abused. Force-release operations require elevated approval to prevent unauthorized or accidental claim eviction (AST06). ```yaml # AST06 -- Require elevated approval for preemptive claim release resolver: type: MeshResolver config: strategy: priority force_release_policy: require_approval: true # AST06: no auto-preempt without authorization approval_source: coordinator # only the SwarmCoordinator can approve require_reason: true # must provide justification string max_force_releases_per_run: 5 # AST06: cap to prevent abuse cooldown_after_force_release_ms: 5000 # prevent rapid repeated preemptions audit: log_all_force_releases: true include_approver_identity: true alert_on_threshold_exceeded: true ``` ```json { "$schema": "https://cortivex.io/schemas/force-release-request.json", "type": "object", "properties": { "action": { "const": "force_release" }, "file": { "type": "string" }, "current_owner": { "type": "string" }, "requested_by": { "type": "string" }, "approved_by": { "type": "string" }, "reason": { "type": "string", "minLength": 10 }, "approval_token": { "type": "string" }, "ast_risk_id": { "const": "AST06" } }, "required": ["action", "file", "current_owner", "requested_by", "approved_by", "reason", "ast_risk_id"] } ``` MCP tool invocation with approval: ``` cortivex_mesh_resolver({ action: "force_resolve", file: "src/auth/session.ts", winner: "agent-worker-5", approval_token: "apr-9f2e-coordinator", reason: "agent-worker-2 unresponsive for 120s; blocking critical path" }) ``` ### Transaction Rollback Integrity When rolling back file modifications in `all-or-nothing` transaction groups, the system must verify file state before and after the rollback to prevent partial rollbacks or state corruption (AST06). ```yaml # AST06 -- Verify file integrity during transaction rollback resolver: config: transactions: enabled: true rollback_integrity: verify_pre_state: true # AST06: hash file content before rollback verify_post_state: true # AST06: confirm rollback restored original hash_algorithm: sha256 on_integrity_mismatch: halt_and_alert # do not proceed if hashes diverge preserve_rollback_evidence: true # keep copies of pre/post state evidence_retention_hours: 72 groups: - name: auth-refactor files: [src/auth/login.ts, src/auth/session.ts] atomicity: all-or-nothing rollback_on_failure: true ``` ```json { "tool": "cortivex_mesh_resolver", "request": { "action": "verify_rollback", "transaction_id": "txn-3f8a", "checks": ["pre_state_hash_match", "post_state_hash_match", "no_partial_writes"] } } ``` Response: ```json { "transaction_id": "txn-3f8a", "status": "rollback_verified", "files": [ { "path": "src/auth/login.ts", "pre_hash": "sha256:a1b2c3d4...", "post_hash": "sha256:a1b2c3d4...", "match": true }, { "path": "src/auth/session.ts", "pre_hash": "sha256:e5f6a7b8...", "post_hash": "sha256:e5f6a7b8...", "match": true } ], "integrity": "verified", "ast_risk_id": "AST06" } ``` ### Deadlock Detection Timeout Limits Unbounded deadlock detection intervals create resource starvation attack vectors where a malicious or buggy agent can hold claims indefinitely. Strict timeout limits prevent agents from monopolizing resources (AST06). ```yaml # AST06 -- Bound deadlock detection to prevent resource starvation resolver: config: deadlock_detection: true deadlock_security: max_claim_hold_seconds: 600 # AST06: absolute max any agent can hold a file max_wait_seconds: 120 # AST06: max time waiting for a contested file max_detection_cycles: 50 # prevent infinite detection loops starvation_detection: enabled: true # detect agents repeatedly denied access threshold_consecutive_denials: 5 on_starvation: escalate_to_coordinator timeout_actions: on_claim_timeout: force_release_and_requeue on_wait_timeout: reassign_task on_detection_loop: halt_and_alert ``` ```typescript import { MeshSecurity } from "@cortivex/mesh"; // AST06: Configure starvation prevention at runtime const meshSecurity = new MeshSecurity({ maxClaimHoldSeconds: 600, maxWaitSeconds: 120, starvationDetection: { enabled: true, consecutiveDenialThreshold: 5, onStarvation: (event) => { meshSecurity.escalate({ agent: event.agentId, file: event.contestedFile, denials: event.consecutiveDenials, astRiskId: "AST06", }); }, }, }); ``` ### Protocol Switching Authorization Switching coordination protocols at runtime (e.g., from `pessimistic-locking` to `optimistic-concurrency`) changes the security posture of the entire pipeline. Protocol switches must require explicit approval and must be logged for audit purposes (AST06). ```json { "$schema": "https://cortivex.io/schemas/protocol-switch-policy.json", "type": "object", "properties": { "protocol_switching": { "type": "object", "properties": { "require_approval": { "type": "boolean", "default": true }, "allowed_transitions": { "type": "array", "items": { "type": "object", "properties": { "from": { "enum": ["pessimistic-locking", "optimistic-concurrency", "hybrid"] }, "to": { "enum": ["pessimistic-locking", "optimistic-concurrency", "hybrid"] }, "approval_level": { "enum": ["coordinator", "admin", "quorum"] } }, "required": ["from", "to", "approval_level"] } }, "deny_by_default": { "type": "boolean", "default": true }, "ast_risk_id": { "const": "AST06" } } } } } ``` ```yaml # AST06 -- Restrict protocol transitions to authorized parties resolver: config: protocol_switching: require_approval: true # AST06: no silent protocol changes deny_by_default: true # unlisted transitions are blocked allowed_transitions: - from: pessimistic-locking to: optimistic-concurrency approval_level: admin # AST06: elevated approval required - from: optimistic-concurrency to: pessimistic-locking approval_level: coordinator # downgrade is less risky - from: pessimistic-locking to: hybrid approval_level: coordinator audit: log_all_switch_requests: true log_denied_switches: true alert_on_unapproved_attempt: true ``` MCP tool for authorized protocol switch: ``` cortivex_coordination_configure({ action: "set_protocol", run_id: "ctx-d4e5f6", protocol: "optimistic-concurrency", approval_token: "apr-admin-7c3e", reason: "Switching to optimistic for read-heavy phase of migration" }) ``` ### Conflict Resolution Audit Trail Every conflict resolution decision must produce an immutable audit record. The audit trail captures who was involved, what strategy was applied, the outcome, and a timestamp, enabling post-incident forensic analysis (AST06). ```json { "$schema": "https://cortivex.io/schemas/conflict-audit-record.json", "type": "object", "properties": { "record_id": { "type": "string", "pattern": "^aud-[a-f0-9]{8}$" }, "conflict_id": { "type": "string" }, "timestamp": { "type": "string", "format": "date-time" }, "agents_involved": { "type": "array", "items": { "type": "string" } }, "contested_file": { "type": "string" }, "strategy_applied": { "enum": ["priority", "first-claim", "preempt", "partition", "serialize"] }, "winner": { "type": "string" }, "loser_action": { "enum": ["requeued", "reassigned", "waited", "halted"] }, "approval_token": { "type": ["string", "null"] }, "force_release": { "type": "boolean" }, "integrity_verified": { "type": "boolean" }, "ast_risk_id": { "const": "AST06" } }, "required": ["record_id", "conflict_id", "timestamp", "agents_involved", "contested_file", "strategy_applied", "ast_risk_id"] } ``` ```yaml # AST06 -- Immutable audit trail for all conflict resolutions resolver: config: audit_trail: enabled: true # AST06: mandatory in production storage: .cortivex/mesh/audit/ format: jsonl # append-only JSON lines include_fields: - conflict_id - timestamp - agents_involved - contested_file - strategy_applied - winner - approval_token - force_release - integrity_verified retention_days: 90 immutable: true # AST06: no modification or deletion sign_records: true # ed25519 signature on each record signature_key_path: /etc/cortivex/keys/audit.key ``` Query the audit trail through the MCP tool: ``` cortivex_mesh_resolver({ action: "audit_query", run_id: "ctx-d4e5f6", filters: { "force_release": true, "time_range": { "from": "2025-01-15T00:00:00Z", "to": "2025-01-16T00:00:00Z" } } }) ```