@raishin/vanguard-frontier-agentic 3.5.0 → 3.6.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@raishin/vanguard-frontier-agentic",
-  "version": "3.5.0",
+  "version": "3.6.0",
   "description": "Cloud and zero-trust agentic workflow marketplace for skills, agents, rules, MCP references, and compliance-aware architecture.",
   "license": "Apache-2.0",
   "repository": {

package/plugins/vanguard-frontier-agentic/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vanguard-frontier-agentic",
-  "version": "3.5.0",
+  "version": "3.6.0",
   "description": "Curated marketplace for cloud and zero-trust AI workflows. 331 agents, 286 skills, and rules across AWS, Azure, OCI, GCP, Alibaba Cloud, Huawei Cloud, Kubernetes, and Terraform.",
   "author": {
     "name": "Raishin",

package/powers/README.md

@@ -1,6 +1,6 @@
 # `powers/` — Kiro Powers
 
-This directory holds **43 Kiro Powers** for `vanguard-frontier-agentic`, one
+This directory holds **44 Kiro Powers** for `vanguard-frontier-agentic`, one
 per cloud/platform/IaC provider. Each Power is a directory containing a
 `POWER.md` file with strict-5 frontmatter and steering content.
 
@@ -45,6 +45,7 @@ powers/
 ├── vanguard-ovhcloud/POWER.md
 ├── vanguard-php/POWER.md
 ├── vanguard-prometheus/POWER.md
+├── vanguard-python/POWER.md
 ├── vanguard-salesforce/POWER.md
 ├── vanguard-sap/POWER.md
 ├── vanguard-scaleway/POWER.md
@@ -87,7 +88,7 @@ cd vanguard-frontier-agentic
 ## How to update
 
 ```bash
-# Regenerate the 43 Powers from catalog/agents.json + per-provider config:
+# Regenerate the 44 Powers from catalog/agents.json + per-provider config:
 npm run kiro-powers:write
 
 # Then verify everything is in sync:

package/powers/vanguard-microsoft/POWER.md

@@ -15,7 +15,7 @@ Activate when the task references Microsoft services, resources, or operations.
 
 ## Routing pattern
 
-- **`copilot-governance-maestro-agent`** — classifies and routes the task to the right specialist
+- **`microsoft-maestro-agent`** — classifies and routes the task to the right specialist
 
 Use the maestro as the entry point: classify the task, then dispatch to one specialist or a parallel team of specialists. Never have the maestro itself execute a live mutation.
 

package/powers/vanguard-netsuite/POWER.md

@@ -1,13 +1,13 @@
 ---
 name: "vanguard-netsuite"
 displayName: "Vanguard Frontier — Netsuite"
-description: "Curated Netsuite agents for netsuite administrator, netsuite ai connector mcp, netsuite ai foundations, netsuite application developer. Routes via netsuite-maestro-agent to specialist agents based on task scope. Static review only; no live mutations."
+description: "Curated Netsuite agents for netsuite administrator, netsuite ai connector mcp, netsuite ai foundations, netsuite application developer. Routes via netsuite-maestro-agent to specialist or live-guard agents based on task scope. Live-mutation agents require approval, target confirmation, evidence capture, and a rollback plan; static specialists never mutate."
 keywords: ["netsuite", "static-review", "configuration-audit", "best-practices"]
 author: "Raishin"
 ---
 # Vanguard Frontier — Netsuite
 
-Curated Netsuite agents for netsuite administrator, netsuite ai connector mcp, netsuite ai foundations, netsuite application developer. Routes via netsuite-maestro-agent to specialist agents based on task scope. Static review only; no live mutations.
+Curated Netsuite agents for netsuite administrator, netsuite ai connector mcp, netsuite ai foundations, netsuite application developer. Routes via netsuite-maestro-agent to specialist or live-guard agents based on task scope. Live-mutation agents require approval, target confirmation, evidence capture, and a rollback plan; static specialists never mutate.
 
 ## When to engage this Power
 
@@ -27,9 +27,9 @@ Live-guard agents enforce approval, target confirmation, evidence capture, and r
 
 ## Invariants
 
-- Live-guard agents (netsuite-live-*) must never be auto-dispatched; require explicit approval and rollback plan.
+- Live-guard agents (the mutating-runtime operators) must never be auto-dispatched; require explicit approval, evidence capture, and a rollback plan. Read-only-runtime and static-review agents on this board are not guards.
 - Route all tasks through netsuite-maestro-agent for proper classification and dispatch.
-- Static review only -- agents analyze configuration and provide findings without mutating live systems.
+- Mixed-tier board: static specialists analyze configuration without mutating live systems; live-guard agents mutate only under approval, target confirmation, evidence capture, and a pre-approved rollback plan.
 
 ## Where the agents live
 

package/powers/vanguard-python/POWER.md

@@ -0,0 +1,47 @@
+---
+name: "vanguard-python"
+displayName: "Vanguard Frontier — Python"
+description: "Curated Python agents for python application security, python async concurrency reliability, python business critical automation governance, python container serverless runtime. Routes static review via python-maestro-agent and live control-plane work via python-live-governance-maestro-agent, which alone gates the live-guard operators. Live mutations require approval, target confirmation, evidence capture, and a rollback plan; static specialists never mutate."
+keywords: ["python", "asyncio", "pyproject", "dependency-confusion", "static-review"]
+author: "Raishin"
+---
+# Vanguard Frontier — Python
+
+Curated Python agents for python application security, python async concurrency reliability, python business critical automation governance, python container serverless runtime. Routes static review via python-maestro-agent and live control-plane work via python-live-governance-maestro-agent, which alone gates the live-guard operators. Live mutations require approval, target confirmation, evidence capture, and a rollback plan; static specialists never mutate.
+
+## When to engage this Power
+
+Activate when the task references Python services, resources, or operations. Do not activate on unrelated requests — narrow keyword matching is required to avoid false activations (Kiro Powers convention).
+
+## Routing pattern
+
+- **`python-maestro-agent`** — classifies and routes the task to the right specialist
+- **`python-live-governance-maestro-agent`** — the live control-plane router; the only entry point that may place a live-guard operator in `live-guard-gate`
+
+This board has two planes with two routers. Send static-review work to `python-maestro-agent` — its contract refuses live operations, so it must never be given a mutation task. Send live control-plane work to `python-live-governance-maestro-agent`, which is the only router that gates the live-guard operators below. Classify first, then dispatch to one specialist or a small parallel team; never have either maestro execute a mutation itself.
+
+## Live-guard agents (gate_mode only)
+
+- `python-live-code-remediation-agent` — never auto-dispatched; gate_mode only
+- `python-live-data-change-control-agent` — never auto-dispatched; gate_mode only
+- `python-live-job-control-agent` — never auto-dispatched; gate_mode only
+- `python-live-model-promotion-control-agent` — never auto-dispatched; gate_mode only
+- `python-live-release-control-agent` — never auto-dispatched; gate_mode only
+- `python-live-rollback-and-recovery-agent` — never auto-dispatched; gate_mode only
+
+Live-guard agents enforce approval, target confirmation, evidence capture, and rollback plans before executing a mutation. They are never auto-dispatched — `python-live-governance-maestro-agent` must place them in `live-guard-gate` or `runtime-evidence-gate` mode.
+
+## Invariants
+
+- Live-guard agents (the mutating-runtime operators) must never be auto-dispatched; require explicit approval, evidence capture, and a rollback plan, and may only be gated by python-live-governance-maestro-agent. Read-only-runtime and static-review agents on this board are not guards.
+- Route static-review tasks through python-maestro-agent and live control-plane tasks through python-live-governance-maestro-agent; never send a live-mutation task to python-maestro-agent, whose contract refuses live operations.
+- Mixed-tier board: static specialists analyze configuration without mutating live systems; live-guard agents mutate only under approval, target confirmation, evidence capture, and a pre-approved rollback plan.
+
+## Where the agents live
+
+Agent specs and adapters are part of the [Vanguard Frontier Agentic](https://github.com/Raishin/vanguard-frontier-agentic) marketplace. For this provider, see `agents/python/` in that repository. All 35 agents in this provider ship a Kiro adapter (`harnesses/kiro-ide.agent.md`, `kiro-cli.agent.json`).
+
+## Companion install paths
+
+- **Claude Code:** `/plugin marketplace add Raishin/vanguard-frontier-agentic` then `/plugin install vanguard-frontier-agentic@vanguard-frontier-agentic`
+- **Codex / Copilot / Cursor / Gemini CLI / Kiro (file export):** `npx vfa-export-agents --platform <harness> --provider python --repo .`

package/powers/vanguard-sap/POWER.md

@@ -21,8 +21,10 @@ Use the maestro as the entry point: classify the task, then dispatch to one spec
 
 ## Live-guard agents (gate_mode only)
 
-- `sap-live-readonly-identity-trust-discovery-agent` — never auto-dispatched; gate_mode only
-- `sap-live-readonly-landscape-discovery-agent` — never auto-dispatched; gate_mode only
+- `sap-btp-entitlement-guarded-operator-agent` — never auto-dispatched; gate_mode only
+- `sap-guarded-transport-import-operator-agent` — never auto-dispatched; gate_mode only
+- `sap-integration-flow-guarded-operator-agent` — never auto-dispatched; gate_mode only
+- `sap-role-assignment-guarded-operator-agent` — never auto-dispatched; gate_mode only
 
 Live-guard agents enforce approval, target confirmation, evidence capture, and rollback plans before executing a mutation. They are never auto-dispatched — the maestro must place them in `live-guard-gate` or `runtime-evidence-gate` mode.
 

package/schemas/agent.schema.json

@@ -79,7 +79,8 @@
         "velero",
         "nvidia",
         "claude",
-        "marketing"
+        "marketing",
+        "python"
       ]
     },
     "harnesses": {

package/schemas/audit-event.schema.json

@@ -0,0 +1,110 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://github.com/Raishin/vanguard-frontier-agentic/schemas/audit-event.schema.json",
+  "title": "Live Control Plane Audit Event",
+  "description": "Contract for the immutable audit event every observation and action in the Python live control plane must emit. This repo defines the CONTRACT; the deploying organization's runtime is responsible for actually emitting, append-only storing, integrity-protecting, time-synchronizing, and retention-managing these events. If audit logging is unavailable for an R3, R4, or R5 action, the acting agent must fail closed and refuse. Emitting an event is not proof the action was authorized or effective — it is one input to control testing.",
+  "type": "object",
+  "required": [
+    "event_id",
+    "event_type",
+    "timestamp",
+    "agent_id",
+    "agent_version",
+    "policy_bundle_version",
+    "caller_identity",
+    "effective_identity",
+    "target",
+    "environment",
+    "risk_tier",
+    "request_digest",
+    "input_classification"
+  ],
+  "properties": {
+    "event_id": { "type": "string", "description": "Immutable, unique event identifier." },
+    "event_type": {
+      "enum": ["observe", "plan", "gate", "approve", "execute", "verify", "reconcile", "rollback", "exception", "seal"]
+    },
+    "timestamp": { "type": "string", "format": "date-time", "description": "Trusted, time-synchronized timestamp (RFC 3339)." },
+    "agent_id": { "type": "string" },
+    "model_id": { "type": "string", "description": "Model identifier, only where policy permits recording it." },
+    "agent_version": { "type": "string" },
+    "skill_version": { "type": "string" },
+    "policy_bundle_version": { "type": "string", "description": "Version of the machine-readable policy bundle evaluated." },
+    "tool_name": { "type": "string" },
+    "tool_version": { "type": "string" },
+    "caller_identity": { "type": "string", "description": "Verified human/requester identity. Must be an identified individual principal — never a shared or unidentified identity for R3+ actions." },
+    "effective_identity": { "type": "string", "description": "Service/JIT identity the action ran as." },
+    "target": { "type": "object", "description": "Exact target of the action (system, resource, revision, scope)." },
+    "environment": { "enum": ["development", "test", "staging", "production"] },
+    "risk_tier": {
+      "enum": ["R0", "R1", "R2", "R3", "R4", "R5"],
+      "description": "Action risk tier of the event's action, R0 (read-only, non-sensitive) through R5 (irreversible / high-blast-radius production mutation). REQUIRED on every event: the approval-binding rules below are conditioned on it, so an optional risk_tier would let an emitter escape them by simply not declaring the tier. Classifying the action is part of the contract, not an optional annotation."
+    },
+    "request_digest": { "type": "string", "description": "Hash of the original request." },
+    "input_classification": {
+      "enum": ["public", "internal", "confidential", "restricted"]
+    },
+    "approval_id": { "type": "string", "description": "Reference to the external, independent approval. Required for gate/approve/execute on R3+; must be bound to the exact target and plan_digest." },
+    "plan_digest": { "type": "string" },
+    "before_state_digest": { "type": "string" },
+    "action": { "type": "object" },
+    "result": { "type": "object" },
+    "after_state_digest": { "type": "string" },
+    "verification": { "type": "object", "description": "Post-action verification result. Must be produced independently of the executor's own claim." },
+    "reconciliation": { "type": "object", "description": "Business reconciliation result — distinct from technical completion." },
+    "rollback": { "type": "object", "description": "Reference to the pre-approved rollback procedure and its readiness." },
+    "control_results": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "required": ["control_id", "result"],
+        "properties": {
+          "control_id": { "type": "string" },
+          "result": { "enum": ["pass", "fail", "not-applicable", "exception"] },
+          "evidence_digest": { "type": "string" }
+        },
+        "additionalProperties": true
+      }
+    },
+    "policy_exceptions": {
+      "type": "array",
+      "items": { "type": "string", "description": "Exception ids in force for this action, each with owner, scope, expiry, and compensating control." }
+    },
+    "redactions": {
+      "type": "array",
+      "items": { "type": "string", "description": "Fields redacted/tokenized before emission for data minimization." }
+    },
+    "parent_event_id": { "type": "string", "description": "Trace parent, linking the operating-model chain (observe -> plan -> gate -> ...)." },
+    "evidence_digest": { "type": "string", "description": "Hash sealing this event's evidence bundle." }
+  },
+  "allOf": [
+    {
+      "$comment": "R3+ gate/approve/execute events must carry the approval binding: an approval_id (bound to the exact target and plan) and the plan_digest it was granted against. An unbound gate/approve/execute at R3+ is exactly the permission-vs-authority and approval-vs-execution confusion this contract exists to prevent, so the schema requires the binding rather than trusting the free-text descriptions.",
+      "if": {
+        "required": ["risk_tier", "event_type"],
+        "properties": {
+          "risk_tier": { "enum": ["R3", "R4", "R5"] },
+          "event_type": { "enum": ["gate", "approve", "execute"] }
+        }
+      },
+      "then": {
+        "required": ["approval_id", "plan_digest"]
+      }
+    },
+    {
+      "$comment": "An R3+ execute additionally requires a before_state_digest (so the change is anchored to a known prior state and verification/rollback are meaningful) and a rollback reference (the pre-approved procedure and its readiness). Execution without a captured before-state or a rollback plan is not accountable execution.",
+      "if": {
+        "required": ["risk_tier", "event_type"],
+        "properties": {
+          "risk_tier": { "enum": ["R3", "R4", "R5"] },
+          "event_type": { "const": "execute" }
+        }
+      },
+      "then": {
+        "required": ["before_state_digest", "rollback"]
+      }
+    }
+  ],
+  "$comment": "Fail-closed rule: an R3/R4/R5 action MUST NOT proceed if this event cannot be emitted to an append-only, integrity-protected, access-controlled store. The acting agent refuses rather than acting without an audit trail. This schema does not implement the store; it specifies what the store must accept.",
+  "additionalProperties": true
+}

package/schemas/control-object.schema.json

@@ -0,0 +1,153 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://github.com/Raishin/vanguard-frontier-agentic/schemas/control-object.schema.json",
+  "title": "Compliance Control Object",
+  "description": "Control-as-code object for the Python live control plane. A control object declares an objective, the mechanisms that enforce and detect it, the evidence it requires, and its failure behavior. It is a control DEFINITION, not a compliance claim: framework_mappings are candidate references a control owner must confirm applicable, and required_evidence lists inputs that support (never by themselves prove) the control.",
+  "type": "object",
+  "required": [
+    "control_id",
+    "title",
+    "objective",
+    "applicability",
+    "required_evidence",
+    "failure_behavior",
+    "control_owner"
+  ],
+  "properties": {
+    "control_id": {
+      "type": "string",
+      "description": "Stable dotted identifier, e.g. organization.change.production-approval.",
+      "pattern": "^[a-z0-9]+(\\.[a-z0-9-]+)+$"
+    },
+    "title": {
+      "type": "string",
+      "minLength": 8
+    },
+    "framework_mappings": {
+      "type": "array",
+      "description": "Candidate framework references. A mapping indicates a control this object may help support; it does not establish that the framework or control applies. Applicability is an owner determination.",
+      "items": {
+        "type": "object",
+        "required": ["framework", "control"],
+        "properties": {
+          "framework": {
+            "type": "string",
+            "enum": [
+              "NIST-SP-800-53",
+              "NIST-CSF",
+              "NIST-AI-RMF",
+              "NIST-GenAI-Profile",
+              "ISO-IEC-27001",
+              "ISO-IEC-42001",
+              "SOC2",
+              "PCI-DSS",
+              "HIPAA-Security-Rule",
+              "SOX-ITGC",
+              "GDPR",
+              "EU-AI-Act",
+              "NIS2",
+              "internal-secure-development",
+              "internal-change-management",
+              "internal-ai-use",
+              "customer-contractual"
+            ]
+          },
+          "control": {
+            "type": "string",
+            "description": "Specific control reference within the framework, e.g. CM-3, CC8.1, Art. 21(2)(f)."
+          },
+          "mapping_confidence": {
+            "enum": ["candidate", "owner-confirmed"],
+            "description": "Defaults to candidate. Only an accountable owner may raise this to owner-confirmed; agents never set it."
+          }
+        },
+        "additionalProperties": false
+      }
+    },
+    "applicability": {
+      "type": "object",
+      "description": "Conditions under which the control is in force. Determined against the applicability engine; presence here is a proposal, not a legal classification.",
+      "required": ["action_risk"],
+      "properties": {
+        "environments": {
+          "type": "array",
+          "items": { "enum": ["development", "test", "staging", "production"] }
+        },
+        "action_risk": {
+          "type": "array",
+          "description": "Action risk tiers R0 (read-only, non-sensitive) through R5 (irreversible / high-blast-radius production mutation). REQUIRED: the warn-rejection rule below is conditioned on this array, so an optional action_risk would let a production-mutation control keep failure_behavior \"warn\" simply by not declaring its risk. Classifying the governed action is part of defining the control.",
+          "minItems": 1,
+          "items": { "enum": ["R0", "R1", "R2", "R3", "R4", "R5"] }
+        },
+        "data_categories": {
+          "type": "array",
+          "items": { "type": "string" }
+        }
+      },
+      "additionalProperties": true
+    },
+    "objective": {
+      "type": "string",
+      "minLength": 20,
+      "description": "What the control is intended to achieve, in outcome terms."
+    },
+    "preventive_mechanisms": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "detective_mechanisms": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "required_evidence": {
+      "type": "array",
+      "minItems": 1,
+      "description": "Evidence inputs the control requires. Existence of this evidence supports but does not prove the control operated or is effective.",
+      "items": { "type": "string" }
+    },
+    "failure_behavior": {
+      "enum": ["block", "warn", "gate-to-human"],
+      "description": "What happens when the control's preconditions are not met. Production mutations (R3+) must be block or gate-to-human, never warn."
+    },
+    "control_owner": {
+      "type": "string",
+      "description": "Accountable owning function (e.g. change-management, security, data-governance). Not the agent."
+    },
+    "test_frequency": {
+      "enum": ["per-action", "daily", "weekly", "monthly", "quarterly", "continuous"]
+    },
+    "exception_process": {
+      "type": "string",
+      "description": "control_id of the exception-governance process that may grant a time-boxed exception."
+    },
+    "limitations": {
+      "type": "array",
+      "description": "Explicit statements of what this control does NOT establish (e.g. legal permissibility, application-owner acceptance, independent assessment).",
+      "items": { "type": "string" }
+    }
+  },
+  "allOf": [
+    {
+      "$comment": "A control that governs a production mutation (R3+) must fail closed: block or gate-to-human. 'warn' is not a control for irreversible/high-blast-radius actions, so it is rejected whenever applicability.action_risk includes R3, R4, or R5. This enforces the failure_behavior description rather than leaving it advisory.",
+      "if": {
+        "required": ["applicability"],
+        "properties": {
+          "applicability": {
+            "required": ["action_risk"],
+            "properties": {
+              "action_risk": {
+                "contains": { "enum": ["R3", "R4", "R5"] }
+              }
+            }
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "failure_behavior": { "enum": ["block", "gate-to-human"] }
+        }
+      }
+    }
+  ],
+  "additionalProperties": false
+}

package/schemas/skill.schema.json

@@ -79,7 +79,8 @@
         "claude",
         "marketing",
         "accounting",
-        "finance"
+        "finance",
+        "python"
       ]
     },
     "harnesses": {