What is the trigger?
│
├── "I wrote a new skill / is it safe?"
│   └── PHASE 1 → PHASE 2 → PHASE 3
│
├── "Scan the Ecosystem"
│   └── PHASE 1 (all skills) → PHASE 2 → PHASE 3
│
├── "The skill will run in production"
│   └── PHASE 1 → PHASE 2 → PHASE 3 → PHASE 4 (activate guard)
│
├── Attack detection (from adaptive-guard)
│   └── PHASE 5 (incident response)
│
├── "Guard is too slow / blocks too often"
│   └── PHASE 6 (guard calibration)
│
└── Periodic check
    └── PHASE 7 (health report)

Ask (or extract from context):
□ Is it a single skill or the ecosystem being scanned?
□ Goal: audit / trust / guard setup / all?
□ Environment: dev / staging / production?
□ Is there an active attack? (is it urgent?)

ACTIVE ATTACK?     → Skip to PHASE 5 (urgent response)
PROD DEPLOYMENT?   → Full flow (PHASES 1-4)
GENERAL CHECK?     → Fast flow (PHASES 1-3)

For the target skill(s):
1. Load SKILL.md
2. Scan the 7 threat categories
3. Extract concrete findings for each category
4. Generate security-report.md

🔴 CRITICAL FINDING EXISTS →
  "This skill cannot be deployed. Pending fixes."
  Send the user the list of necessary fixes
  Do not move to PHASE 3 — fix first

🟡 MODERATE RISK EXISTS →
  "Appropriate for limited use. Suggested fixes."
  Proceed to PHASE 3

🟢 CLEAN →
  Proceed to PHASE 3

1. Fetch Audit results
2. Calculate Trust score (0-100)
3. Set trust level
4. Build permission map
5. Generate trust-score.md

trust_context = {
    "skill_name": "...",
    "trust_score": N,
    "trust_level": "TRUSTED|NORMAL|RESTRICTED|QUARANTINED",
    "permitted_actions": [...],
    "denied_actions": [...],
    "requires_checkpoint": [...]
}

RESTRICTED or QUARANTINED (0-59):
  → K4 Human approval mandatory for every execution
  → K1 threshold lowered (tighter scanning)
  → All external API calls blocked

NORMAL (60-79):
  → K3 LLM judge active for suspicious cases
  → Whitelisted APIs permitted
  → File write requires checkpoint

TRUSTED (80-100):
  → Standard K0-K2 sufficient
  → K3 only on anomalies
  → Human approval only for critical actions

adaptive_guard_config = {
    "skill": skill_name,
    "trust_score": N,
    "fail_policy": "fail-open|fail-closed",  # Pick based on trust
    "k2_active": true|false,              # Does ML infra exist?
    "k4_timeout": 1800,                   # 30 minutes
    "learning_active": true,
    "cache_ttl": 86400,                   # 24 hours
    "anomaly_multiplier": 5
}

"Normal interaction baseline being established for adaptive-guard
on this skill. Monitoring mode active for the first 48 hours
(logging without blocking). Full protection follows thereafter."

📋 Guard Activation Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Skill         : [name]
Trust Score   : [N]/100 → [level]
Fail Policy   : [fail-open|fail-closed]
K2 ML Filter  : [active|disabled]
Learning Mode : active
Monitoring    : 48 hours (then full protection)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Proceed with activation?

STEP 1 — Isolate immediately
  → Suspend attacker's session
  → Temporarily disable the associated skill

STEP 2 — Analyze
  security-auditor → Re-audit the impacted skill
  adaptive-guard → Extract incident-report.md details

STEP 3 — Rule update
  → Detect attack class
  → Manually trigger learning engine
  → Append new rule (automatic if confidence >0.60)

STEP 4 — Report
  To the user:
  ┌─────────────────────────────────────────┐
  │ 🚨 Security Incident Detected          │
  │                                         │
  │ Type     : [attack class]               │
  │ Time     : [timestamp]                  │
  │ Skill    : [impacted skill]             │
  │ Action   : [what occurred]              │
  │ New Rule : [learned rule pattern]       │
  └─────────────────────────────────────────┘

STEP 5 — De-isolate / Re-open
  If patched → reactivate skill
  If unpatched → keep quarantined

1. Inspect the last 100 blocks
2. Identify unjustified blocks
3. Loosen or drop the exact K1 rule responsible
4. Add to Whitelist (if necessary)
5. Monitor for 24 hours, recalculate rates

K0 cache hit rate < 60% → Increase Cache TTL
K2 traffic > 20%        → Strengthen K1 rules (send fewer to K2)
K3 traffic > 5%         → Fine-tune the K2 model

undefined

---

1. adaptive-guard is never fully turned off
   → Only sensitivities (K1/K2/K3) can be manually bypassed

2. If security-auditor audit FAILED
   → Skill cannot go to production
   → Enforced strictly by Orchestrator

3. If Trust score < 40
   → Orchestrator clearly alerts the user
   → Asks: "This skill is quarantined, still want to use it?"

4. The Guard displays every learned rule
   → Principle: "No implicit rule is applied without notification"

5. Incident sequence: isolate → analyze → learn → report → re-open
   → Steps cannot be skipped

6. Every orchestrator decision is logged
   → Appended to security-audit-trail.log
   → Traceability of exactly who/what made the decision