@esoteric-logic/praxis-harness 3.0.0 → 3.1.0

package/base/hooks/settings-hooks.json

@@ -63,16 +63,16 @@
         "matcher": "",
         "hooks": [
           {
-            "type": "prompt",
-            "prompt": "Run the project test suite. Read CLAUDE.md ## Commands for the test command. If no test command defined, respond {ok:true}. Run tests. If all pass: respond {ok:true}. If tests fail: respond {ok:false, reason:'Tests failing: <summary>'}. Do not fix — only report."
+            "type": "command",
+            "command": "bash ~/.claude/hooks/stop-prompt-gate.sh test-runner"
           },
           {
             "type": "command",
             "command": "bash ~/.claude/hooks/session-data-collect.sh"
           },
           {
-            "type": "prompt",
-            "prompt": "You are completing a session. Perform these vault updates silently — no confirmation needed.\n\n1. Read vault_path from ~/.claude/praxis.config.json. If missing: skip all steps.\n2. Read {vault_path}/.session-staging.json if it exists (structured session data from hooks).\n3. Update {vault_path}/status.md:\n   - Set last_updated to today, last_session to now (ISO timestamp)\n   - Update loop_position based on where the session ended\n   - Refresh What / So What / Now What sections with session accomplishments\n   - If >100 lines: archive resolved items to notes/{date}_status-archive.md\n4. Update {vault_path}/claude-progress.json:\n   - Enrich the latest sessions[] entry (added by hook) with: summary (1 line), accomplishments (array)\n   - If jq hook did not run (no sessions[] entry for today): create the full entry\n   - Update milestones[] if any milestones were completed this session\n   - Update features[] if any features were shipped this session\n5. Write {vault_path}/notes/{YYYY-MM-DD}_session-note.md with frontmatter (tags: [session, {project-slug}], date, source: agent) containing:\n   - Summary (3-5 bullets of what was accomplished)\n   - Decisions Made (checkpoint decisions, scope changes, approach choices made this session)\n   - Learnings (any [LEARN:tag] entries from this session)\n   - Next Session (what to pick up next)\n6. If checkpoint decisions, scope expansions, or rule proposals occurred this session:\n   - Append each to {vault_path}/notes/decision-log.md with date, decision type, context, decision, and rationale\n7. If corrections or patterns were discovered this session:\n   - Append [LEARN:tag] entries to {vault_path}/notes/learnings.md following the existing format\n8. If architectural decisions were made this session:\n   - Write ADR to {vault_path}/specs/ using vault frontmatter conventions\n9. Delete {vault_path}/.session-staging.json if it exists.\n\nKeep all writes concise. Use [[wikilinks]] for internal references. Follow existing YAML frontmatter conventions. If vault_path is missing or vault is inaccessible: skip silently. Do not ask permission — this is automatic housekeeping."
+            "type": "command",
+            "command": "bash ~/.claude/hooks/stop-prompt-gate.sh vault-update"
           }
         ]
       }

package/base/hooks/stop-prompt-gate.sh

@@ -0,0 +1,88 @@
+#!/usr/bin/env bash
+# stop-prompt-gate.sh — Gates Stop prompt hooks behind session activity detection.
+# Only outputs the prompt text if the session had substantive work.
+# Silent exit otherwise — prevents infinite Stop hook loops.
+#
+# Usage in settings-hooks.json:
+#   { "type": "command", "command": "bash ~/.claude/hooks/stop-prompt-gate.sh vault-update" }
+#   { "type": "command", "command": "bash ~/.claude/hooks/stop-prompt-gate.sh test-runner" }
+set -uo pipefail
+
+PROMPT_TYPE="${1:-vault-update}"
+CONFIG_FILE="$HOME/.claude/praxis.config.json"
+
+# ── Detect session activity ──
+HAS_RECENT_COMMITS=false
+HAS_DIRTY_TREE=false
+
+RECENT=$(git --no-pager log --oneline --since="1 hour ago" 2>/dev/null | head -1)
+if [[ -n "$RECENT" ]]; then
+  HAS_RECENT_COMMITS=true
+fi
+
+DIRTY=$(git --no-pager status --porcelain 2>/dev/null | head -1)
+if [[ -n "$DIRTY" ]]; then
+  HAS_DIRTY_TREE=true
+fi
+
+# Check staging file from session-data-collect.sh
+STAGING_DIRTY=false
+if [[ -f "$CONFIG_FILE" ]]; then
+  VAULT_PATH=$(jq -r '.vault_path // empty' "$CONFIG_FILE" 2>/dev/null)
+  STAGING_FILE="${VAULT_PATH:+$VAULT_PATH/.session-staging.json}"
+  if [[ -n "$STAGING_FILE" && -f "$STAGING_FILE" ]]; then
+    STAGING_DIRTY=$(jq -r '.git.dirty // false' "$STAGING_FILE" 2>/dev/null)
+  fi
+fi
+
+# ── Gate: no activity → exit silently ──
+if [[ "$HAS_RECENT_COMMITS" == "false" && "$HAS_DIRTY_TREE" == "false" && "$STAGING_DIRTY" != "true" ]]; then
+  exit 0
+fi
+
+# ── Activity detected — output the requested prompt ──
+case "$PROMPT_TYPE" in
+  test-runner)
+    cat << 'PROMPT'
+Run the project test suite. Read CLAUDE.md ## Commands for the test command. If no test command defined, respond {ok:true}. Run tests. If all pass: respond {ok:true}. If tests fail: respond {ok:false, reason:'Tests failing: <summary>'}. Do not fix — only report.
+PROMPT
+    ;;
+  vault-update)
+    cat << 'PROMPT'
+You are completing a session with substantive work. Perform these vault updates silently — no confirmation needed.
+
+1. Read vault_path from ~/.claude/praxis.config.json. If missing: skip all steps.
+2. Read {vault_path}/.session-staging.json if it exists (structured session data from hooks).
+3. Update {vault_path}/status.md:
+   - Set last_updated to today, last_session to now (ISO timestamp)
+   - Update loop_position based on where the session ended
+   - Refresh What / So What / Now What sections with session accomplishments
+   - If >100 lines: archive resolved items to notes/{date}_status-archive.md
+4. Update {vault_path}/claude-progress.json:
+   - Enrich the latest sessions[] entry (added by hook) with: summary (1 line), accomplishments (array)
+   - If jq hook did not run (no sessions[] entry for today): create the full entry
+   - Update milestones[] if any milestones were completed this session
+   - Update features[] if any features were shipped this session
+5. Write {vault_path}/notes/{YYYY-MM-DD}_session-note.md with frontmatter (tags: [session, {project-slug}], date, source: agent) containing:
+   - Summary (3-5 bullets of what was accomplished)
+   - Decisions Made (checkpoint decisions, scope changes, approach choices made this session)
+   - Learnings (any [LEARN:tag] entries from this session)
+   - Next Session (what to pick up next)
+6. If checkpoint decisions, scope expansions, or rule proposals occurred this session:
+   - Append each to {vault_path}/notes/decision-log.md with date, decision type, context, decision, and rationale
+7. If corrections or patterns were discovered this session:
+   - Append [LEARN:tag] entries to {vault_path}/notes/learnings.md following the existing format
+8. If architectural decisions were made this session:
+   - Write ADR to {vault_path}/specs/ using vault frontmatter conventions
+9. Delete {vault_path}/.session-staging.json if it exists.
+
+Keep all writes concise. Use [[wikilinks]] for internal references. Follow existing YAML frontmatter conventions. If vault_path is missing or vault is inaccessible: skip silently. Do not ask permission — this is automatic housekeeping.
+PROMPT
+    ;;
+  *)
+    echo "Unknown prompt type: $PROMPT_TYPE" >&2
+    exit 0
+    ;;
+esac
+
+exit 0

package/bin/prompt-compile.js

@@ -16,7 +16,7 @@ const {
   loadBlocks,
   applyOverrides,
   loadClientConfig,
-  discoverAllDeals,
+  discoverAllWorkProjects,
   resolveProject,
   mergeClientDealConfig,
 } = require('../lib/loader');
@@ -35,8 +35,8 @@ const PROJECTS_DIR = path.join(PROMPTS_DIR, 'projects');
 function discoverAllProjects() {
   const results = [];
 
-  // New hierarchy: clients/*/deals/*/
-  for (const entry of discoverAllDeals()) {
+  // New hierarchy: work/*/projects/* + personal/*
+  for (const entry of discoverAllWorkProjects()) {
     results.push({ name: entry.displayName, dir: entry.dealDir, client: entry.client, deal: entry.deal, clientDir: entry.clientDir });
   }
 

package/lib/loader.js

@@ -163,7 +163,7 @@ function loadClientConfig(clientDir) {
  * Discover all projects across work/ (client → deals) and personal/ (flat).
  * Returns array of { client, deal, dealDir, clientDir, displayName }.
  */
-function discoverAllDeals() {
+function discoverAllWorkProjects() {
   const results = [];
 
   // Work projects: work/<client>/deals/<deal>/
@@ -173,7 +173,7 @@ function discoverAllDeals() {
 
     for (const client of clients) {
       const clientDir = path.join(WORK_DIR, client);
-      const dealsDir = path.join(clientDir, 'deals');
+      const dealsDir = path.join(clientDir, 'projects');
       if (!fs.existsSync(dealsDir)) continue;
 
       const deals = fs.readdirSync(dealsDir)
@@ -226,7 +226,7 @@ function resolveProject(identifier) {
         return { client: 'personal', deal: name, dealDir: projectDir, clientDir: null, legacy: false };
       }
     } else {
-      const dealDir = path.join(WORK_DIR, scope, 'deals', name);
+      const dealDir = path.join(WORK_DIR, scope, 'projects', name);
       const clientDir = path.join(WORK_DIR, scope);
       if (fs.existsSync(dealDir)) {
         return { client: scope, deal: name, dealDir, clientDir, legacy: false };
@@ -235,7 +235,7 @@ function resolveProject(identifier) {
   }
 
   // Search all projects for a matching name
-  const allDeals = discoverAllDeals();
+  const allDeals = discoverAllWorkProjects();
   const match = allDeals.find((d) => d.deal === identifier);
   if (match) {
     return { client: match.client, deal: match.deal, dealDir: match.dealDir, clientDir: match.clientDir, legacy: false };
@@ -301,7 +301,7 @@ module.exports = {
   loadBlocks,
   applyOverrides,
   loadClientConfig,
-  discoverAllDeals,
+  discoverAllWorkProjects,
   resolveProject,
   mergeClientDealConfig,
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@esoteric-logic/praxis-harness",
-  "version": "3.0.0",
+  "version": "3.1.0",
   "description": "Layered Claude Code harness — workflow discipline, AI-Kits, persistent vault integration",
   "bin": {
     "praxis-harness": "./bin/praxis.js",

package/prompts/work/ecs-limited/client-config.yaml

@@ -0,0 +1,9 @@
+client: ecs-limited
+description: ECS Limited — SOC 2 compliance and Zero Trust for Azure
+profile: null
+
+vars: {}
+
+shared_references: []
+
+knowledge_packs: []

package/prompts/work/ecs-limited/projects/soc2-zero-trust/project-instructions-claude-desktop.md

@@ -0,0 +1,32 @@
+## Role
+Solutions architect specializing in SOC 2 compliance and Zero Trust architecture for Microsoft Azure. Helps security architects, compliance officers, and IT leaders design, implement, and audit compliant cloud security postures.
+
+## Behavioral Constraints
+- Lead with recommendations and rationale, not options lists
+- Verify claims against uploaded knowledge files before presenting as fact
+- When uncertain, ask one clarifying question. Flag confidence: HIGH / MEDIUM / LOW
+- Structure every response: answer first, reasoning second, sources third
+
+## Domain Expertise
+- SOC 2 TSC (2017 framework, 2022 Points of Focus): Security, Availability, Processing Integrity, Confidentiality, Privacy
+- SOC 2 Type I vs Type II audit preparation, control mapping, evidence collection
+- Zero Trust: Microsoft Entra ID, Conditional Access, PIM, network segmentation
+- NIST SP 800-207, CISA Zero Trust Maturity Model, Microsoft ZT Maturity Model (2025)
+- Azure security: Defender for Cloud, Sentinel, Defender XDR, Azure Firewall
+
+## Output Format
+- Tables for control mappings and gap analyses
+- Numbered steps for procedures
+- Risk register format for assessments (Threat, Likelihood, Impact, Mitigation)
+- BLUF structure: bottom line, evidence, next steps
+
+## Quality Controls
+- Cross-reference claims against knowledge files. Flag contradictions.
+- Never fabricate version numbers, dates, statistics, or citations
+- Cite specific TSC criteria (CC6.1, CC7.2) and Azure services by name
+- When quoting standards, cite document name and section
+- Flag information older than 12 months: "As of [date] — verify for current status"
+
+## When Uncertain
+State uncertainty explicitly. Ask one clarifying question rather than guessing.
+Flag confidence: HIGH (verified), MEDIUM (corroborated), LOW (inferred/speculative).

package/prompts/work/ecs-limited/projects/soc2-zero-trust/prompt-config.yaml

@@ -0,0 +1,21 @@
+name: ecs-limited
+description: SOC 2 compliance and Zero Trust architecture for Azure
+mode: standalone
+role: solutions-architect
+platforms:
+  - claude-projects
+  - perplexity-spaces
+domains:
+  - soc2-compliance
+  - zero-trust-azure
+  - azure-security
+research_domains:
+  - SOC 2 compliance frameworks and AICPA Trust Services Criteria
+  - Zero Trust architecture for Microsoft Azure (Entra ID, Conditional Access)
+  - Azure security best practices and continuous compliance automation
+knowledge_files:
+  - references/soc2-compliance.md
+  - references/zero-trust-azure.md
+version: "1.0"
+created: 2026-04-05
+last_updated: 2026-04-05

package/prompts/work/ecs-limited/projects/soc2-zero-trust/references/soc2-compliance.md

@@ -0,0 +1,62 @@
+---
+domain: soc2-compliance
+generated: 2026-04-05
+source: perplexity-research
+---
+
+# SOC 2 Compliance — Reference Guide
+
+## Key Concepts & Terminology
+- **SOC 2**: Service Organization Control 2 — audit framework developed by AICPA for service organizations handling customer data
+- **Trust Services Criteria (TSC)**: Five categories that define the scope of a SOC 2 audit
+  - **Security** (Common Criteria) — mandatory for all SOC 2 reports; protects against unauthorized access
+  - **Availability** — system uptime and operational commitments
+  - **Processing Integrity** — accurate, complete, timely processing
+  - **Confidentiality** — protection of restricted information
+  - **Privacy** — personal data collection, use, retention, disclosure, disposal
+- **Type I Report**: Evaluates control design at a single point in time (1-3 month timeline)
+- **Type II Report**: Evaluates control design AND operating effectiveness over 3-12 months (6-12+ month timeline)
+- **Controls**: Policies, procedures, and safeguards mapped to TSC — typically 60-150 control points in a Type II audit
+- **Points of Focus**: Updated in 2022 AICPA SOC 2 Audit Guide — provide clarity on risks, technologies, and vulnerabilities
+
+## Current Standards & Frameworks
+- **AICPA TSC Framework**: 2017 base criteria, 2022 revised Points of Focus (effective through 2026)
+- **2022 Revisions**: Clarified risk assessments (CC1.3/CC1.5 for privacy, CC2.1-2.3 for data management), disclosures on risks/technologies. No core TSC changes.
+- **2025-2026 Trends**: Greater emphasis on zero-trust, vendor risk (CC9.2), continuous monitoring, AI/cloud threat vectors
+- **Confidentiality criteria** now included in 64.4% of reports (up from 34%)
+- **Cross-framework alignment**: SOC 2 commonly mapped to ISO 27001, HIPAA, CMMC
+
+## Best Practices
+- Treat compliance as an ongoing operation, not a one-time project
+- Start with Type I, then progress to Type II for enterprise credibility
+- Scope additional TSC criteria based on specific risks (e.g., Privacy for PII, Availability for SLA-bound services)
+- Automate evidence collection: logs, access reviews, patching records, incident records
+- Maintain an audit calendar with monthly, quarterly, and annual review cadences
+- Inventory all subservice providers and maintain vendor risk assessments (CC9.2)
+- Use compliance platforms for workflow automation and continuous monitoring
+
+## Audit Preparation Workflow
+1. **Gap Analysis & Scoping** (2-4 weeks): Review TSC against current systems, identify control gaps
+2. **Control Implementation** (3-9 months): Deploy MFA, change management, risk assessments, vendor inventory, backups/DR
+3. **Internal Testing**: Vulnerability scans, penetration tests, access reviews
+4. **Evidence Collection**: Automate log gathering, access reviews, patching records; maintain audit trail
+5. **Type I Audit** (4-8 weeks): Point-in-time assessment of control design
+6. **Type II Observation Period** (3-12 months): Demonstrate operating effectiveness
+7. **Type II Audit** (6-10 weeks after observation): Final assessment and report
+
+## Control Categories (Common Criteria)
+- CC1: Control environment (governance, oversight, accountability)
+- CC2: Communication and information (data management, internal/external communication)
+- CC3: Risk assessment (risk identification, analysis, mitigation)
+- CC4: Monitoring activities (ongoing evaluation, deficiency remediation)
+- CC5: Control activities (policies, technology controls, deployment)
+- CC6: Logical and physical access (authentication, authorization, access management)
+- CC7: System operations (detection, incident management, recovery)
+- CC8: Change management (change authorization, testing, deployment)
+- CC9: Risk mitigation (vendor management, business continuity)
+
+## Sources
+- AICPA SOC 2 Audit Guide (2022 revision)
+- Konfirmity: SOC 2 changes in 2026
+- Sprinto: SOC 2 updates
+- Secureframe: Trust Services Criteria guide

package/prompts/work/ecs-limited/projects/soc2-zero-trust/references/zero-trust-azure.md

@@ -0,0 +1,86 @@
+---
+domain: zero-trust-azure
+generated: 2026-04-05
+source: perplexity-research
+---
+
+# Zero Trust Architecture for Azure — Reference Guide
+
+## Key Concepts & Terminology
+- **Zero Trust**: Security model that eliminates implicit trust — every access request is verified regardless of origin
+- **Three Principles**: Verify explicitly, use least privilege access, assume breach
+- **Microsoft Entra ID** (formerly Azure AD): Central identity provider for Zero Trust on Azure
+- **Conditional Access**: Policy engine that evaluates signals (identity, device, location, risk) to enforce access decisions
+- **Privileged Identity Management (PIM)**: Just-in-time (JIT) and just-enough-access (JEA) privilege elevation
+- **Continuous Access Evaluation (CAE)**: Real-time token validation and session controls
+- **Micro-segmentation**: Granular network isolation using Azure Firewall, NSGs, and Private Link
+
+## Current Standards & Frameworks
+- **NIST SP 800-207**: Zero Trust Architecture reference — defines policy enforcement points (PEP), policy decision points (PDP)
+- **CISA Zero Trust Maturity Model** (Identity Pillar):
+  - Initial: Entra ID as IdP, MFA for all apps/guests, Conditional Access with entity attributes
+  - Advanced: Phishing-resistant MFA (FIDO2/CBA), app migration, risk-based policies
+  - Optimal: Real-time risk (ID Protection/Sentinel), CAE, automated governance, cross-tenant sync
+- **Microsoft Zero Trust Maturity Model** (2025 edition): Assess across identity, devices, network, data pillars
+
+## Best Practices
+
+### Identity
+- Deploy Entra ID as the single identity provider; consolidate identity stores
+- Enforce MFA for all users, guests, and service accounts — security defaults deprecated in favor of Conditional Access policies
+- Use phishing-resistant MFA: FIDO2 passkeys, Certificate-Based Authentication (CBA), Windows Hello for Business
+- Block legacy authentication protocols (97-99% of attacks target them)
+- Implement PIM for privileged roles with JIT elevation and approval workflows
+- Use managed identities for service-to-service authentication
+
+### Conditional Access
+- Deploy baseline policies in report-only mode first; monitor 7-14 days via sign-in logs
+- Require MFA, device compliance, and approved apps as baseline conditions
+- Use authentication strengths to enforce phishing-resistant methods for sensitive operations
+- Maintain break-glass accounts excluded from all policies
+- Use risk-based policies (Entra ID Protection) for user and sign-in risk detection
+
+### Network
+- Use Private Link and private endpoints for all PaaS services
+- Segment workloads with Azure Virtual Network and subnet-level NSGs
+- Deploy Azure Firewall for centralized network policy enforcement
+- Implement micro-segmentation to limit lateral movement
+- Use Global Secure Access for compliant network checks
+
+### Monitoring
+- Deploy Microsoft Defender for Cloud; target Azure Secure Score >85%
+- Use Microsoft Sentinel for SIEM/SOAR with UEBA analytics
+- Deploy Defender XDR for extended detection and response
+- Enable diagnostic logging for all identity, network, and application events
+- Configure automated incident response playbooks
+
+## Implementation Steps (Recommended Order)
+1. Deploy Conditional Access baseline policies in report-only mode
+2. Enable MFA enforcement via Conditional Access (replace security defaults)
+3. Migrate to phishing-resistant MFA for privileged users
+4. Implement PIM for administrative roles
+5. Configure network segmentation and private endpoints
+6. Deploy Defender for Cloud + Sentinel for monitoring
+7. Enable CAE and real-time risk assessment
+8. Block legacy authentication protocols
+9. Onboard devices to Intune for device compliance signals
+10. Target and maintain Azure Secure Score >85%
+
+## SOC 2 Mapping
+| Zero Trust Component | SOC 2 TSC Mapping |
+|---------------------|-------------------|
+| MFA / Conditional Access | CC6.1, CC6.2, CC6.3 (Logical Access) |
+| PIM / Least Privilege | CC6.1, CC6.3 (Access Management) |
+| Network Segmentation | CC6.6 (System Boundaries) |
+| Monitoring / Sentinel | CC7.1, CC7.2, CC7.3 (System Operations) |
+| Incident Response | CC7.3, CC7.4 (Incident Management) |
+| Change Management | CC8.1 (Change Authorization) |
+| Vendor Management | CC9.2 (Vendor Risk) |
+| Encryption | CC6.7 (Transmission/Storage) |
+
+## Sources
+- Microsoft: Zero Trust deployment guide for Azure
+- Microsoft Learn: CISA Zero Trust Maturity Model — Identity pillar
+- NIST SP 800-207: Zero Trust Architecture
+- Microsoft Security Blog: Secure Future Initiative and Zero Trust (May 2025)
+- GitHub: Conditional Access baseline policies (October 2025 v2025-10)

package/prompts/work/ecs-limited/projects/soc2-zero-trust/space-instructions-perplexity.md

@@ -0,0 +1,45 @@
+## Purpose
+Solutions architect specializing in SOC 2 compliance and Zero Trust architecture for Microsoft Azure. Helps security architects, compliance officers, and IT leaders design, implement, and audit compliant cloud security postures.
+
+## Domain Expertise
+- SOC 2 Trust Services Criteria (2017 framework, 2022 revised Points of Focus): Security, Availability, Processing Integrity, Confidentiality, Privacy
+- SOC 2 Type I vs Type II audit preparation, control mapping, evidence collection
+- Zero Trust architecture: Microsoft Entra ID, Conditional Access, PIM, network segmentation, micro-segmentation
+- NIST SP 800-207, CISA Zero Trust Maturity Model, Microsoft Zero Trust Maturity Model (2025)
+- Azure security services: Defender for Cloud, Sentinel, Defender XDR, Azure Firewall
+- Continuous compliance automation, vendor risk management (CC9.2)
+
+## Research Domains
+- SOC 2 compliance frameworks, AICPA Trust Services Criteria updates, audit best practices
+- Zero Trust architecture for Microsoft Azure: Entra ID, Conditional Access policies, PIM
+- Azure security best practices: Defender for Cloud, Sentinel, network segmentation
+- NIST SP 800-207 and CISA Zero Trust Maturity Model updates
+- Compliance automation tools and evidence collection for cloud environments
+
+## Source Priority
+1. Microsoft Learn documentation and security blog
+2. AICPA standards and SOC 2 audit guides
+3. NIST publications (SP 800-207, SP 800-63)
+4. CISA Zero Trust Maturity Model documentation
+5. Industry analyst reports and compliance platform guides
+
+## How to Answer
+- Lead with the recommendation, then the reasoning and evidence
+- Use tables for control mappings, gap analyses, and comparisons
+- Use numbered steps for implementation procedures
+- Cite specific TSC criteria (e.g., CC6.1, CC7.2) when discussing SOC 2 controls
+- Cite specific Azure services and configuration options when discussing Zero Trust
+- When mapping Zero Trust to SOC 2, cross-reference both domains explicitly
+
+## Reasoning Approach
+Think step-by-step: Understand the question → search sources → analyze findings → recommend with rationale → verify claims are sourced. Lead with the answer, then the evidence. For complex questions, break into numbered steps and complete each fully before the next.
+
+## Quality & Accuracy Standards
+- Flag confidence level: HIGH (multiple sources confirm), MEDIUM (single source), LOW (inferred)
+- Never fabricate version numbers, statistics, citations, or URLs
+- If sources disagree, cite both and explain the discrepancy
+- When information may be outdated (>12 months), note the publication date
+- If you cannot find reliable sources, state that clearly rather than speculating
+- Distinguish verified facts from analytical inferences
+- Lead with the bottom line, then supporting evidence
+- Structure every response: answer first, reasoning second, sources third

package/prompts/work/ecs-limited/projects/soc2-zero-trust/system-prompt.md

@@ -0,0 +1,79 @@
+---
+version: "1.0"
+date: 2026-04-05
+platform: claude-project
+generated_by: px-prompt
+---
+
+## Role
+You are a solutions architect specializing in SOC 2 compliance and Zero Trust architecture for Microsoft Azure environments. You help security architects, compliance officers, and IT leaders design, implement, and maintain compliant cloud security postures.
+
+## Behavioral Constraints
+- Lead with recommendations, not options lists. State your recommendation and why before presenting alternatives.
+- Verify claims against uploaded knowledge files before presenting as fact. If a standard version or date is uncertain, say so.
+- When uncertain, ask one clarifying question rather than guessing. Flag confidence level: HIGH (verified from sources), MEDIUM (corroborated), LOW (inferred or speculative).
+- Structure every response: answer first, reasoning second, sources third.
+- Use tables for comparisons. Use numbered steps for procedures. Use bullet points for lists of requirements.
+
+## Domain Expertise
+
+### SOC 2 Compliance
+- AICPA Trust Services Criteria (2017 framework, 2022 revised Points of Focus): Security (Common Criteria, mandatory), Availability, Processing Integrity, Confidentiality, Privacy
+- SOC 2 Type I (control design at a point in time) vs Type II (operating effectiveness over 3-12 months)
+- Control mapping to TSC categories: 60-150 control points typical for Type II audits
+- Audit preparation workflow: gap analysis → control implementation → internal testing → evidence collection → auditor engagement
+- Continuous compliance: monthly patching, quarterly access reviews, annual/semi-annual reporting cycles
+- Vendor risk management and subservice provider inventory (CC9.2)
+
+### Zero Trust Architecture — Azure
+- Microsoft Zero Trust principles: verify explicitly, least privilege access, assume breach
+- Microsoft Entra ID (formerly Azure AD): central identity provider, authentication strengths, ID Protection, External ID
+- Conditional Access: MFA enforcement, device compliance, risk-based blocking, phishing-resistant methods (FIDO2, CBA, Windows Hello)
+- Privileged Identity Management (PIM): JIT/JEA elevation
+- Network segmentation: Azure VNet, Private Link, Azure Firewall, NSGs, micro-segmentation
+- Continuous Access Evaluation (CAE), Defender for Cloud, Defender XDR, Sentinel
+
+### Maturity Model Alignment
+- NIST SP 800-207 Zero Trust Architecture
+- CISA Zero Trust Maturity Model (Identity Pillar): Initial → Advanced → Optimal stages
+- Microsoft Zero Trust Maturity Model (2025 edition): identity, devices, network, data pillars
+
+## Output Format
+- Control gap analysis: table (Control ID, TSC Mapping, Current State, Required State, Remediation, Priority)
+- Architecture review: findings table (Severity, Component, Issue, Recommendation)
+- Policy documents: Purpose, Scope, Policy Statements, Procedures, Review Schedule
+- Risk assessments: Threat, Likelihood, Impact, Risk Score, Mitigation, Owner
+
+## Common Tasks
+1. Map Azure configurations to SOC 2 TSC and identify gaps
+2. Design Zero Trust Conditional Access policy baselines
+3. Write or review security policies (access control, incident response, change management)
+4. Create evidence collection plans for audit preparation
+5. Assess network architecture for Zero Trust alignment
+6. Configure monitoring with Defender for Cloud and Sentinel
+7. Evaluate vendor and third-party risk (CC9.2)
+8. Prepare audit-ready control matrices and TSC mappings
+9. Design PIM and RBAC strategies for least privilege
+10. Generate compliance training content
+
+## Knowledge Interaction Rules
+- Check uploaded reference files before answering about standards or controls
+- Cross-reference both domain knowledge files when questions span SOC 2 and Zero Trust
+- Flag when a question falls outside uploaded knowledge scope
+
+## Reasoning Approach
+Think step-by-step: Understand → Research (check knowledge files) → Analyze → Recommend → Verify (are claims sourced?). Complete each step fully before the next. Show reasoning when logic matters.
+
+## Quality Controls
+- Cross-reference claims against knowledge files before presenting as fact
+- Distinguish: verified (from knowledge files), corroborated (multiple sources), inferred, speculative
+- Never fabricate version numbers, dates, statistics, citations, or URLs
+- When quoting standards: cite document name and section
+- If not covered in knowledge files, state that before offering general knowledge
+- Flag information older than 12 months: "As of [date] — verify for current status"
+- Lead with the answer, then reasoning. BLUF structure: bottom line, evidence, next steps
+- Self-check before delivering: Does this answer the question? Are claims sourced?
+
+## When Uncertain
+State uncertainty explicitly. Ask one clarifying question rather than guessing.
+Flag confidence level: HIGH (verified from sources), MEDIUM (corroborated), LOW (inferred or speculative).