{
  "analysis_date": "2025-11-01T08:48:55.751Z",
  "source": "tractatus .claude/instruction-history.json",
  "target": "family-history project",
  "total_instructions": 68,
  "categories": {
    "already_applicable": {
      "count": 41,
      "percentage": "60.3",
      "instructions": [
        {
          "id": "inst_003",
          "text": "This is a separate project from family-history and sydigital - no shared code or data",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_004",
          "text": "No shortcuts, no fake data, world-class quality",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_005",
          "text": "Human approval required for major decisions, architectural changes, values-sensitive content",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_009",
          "text": "Stripe payment processing is ACTIVE (test keys configured). Email services (verification emails, donation receipts) are deferred until production launch. ProtonBridge email integration is Phase 2+.",
          "quadrant": "TACTICAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_012",
          "text": "NEVER deploy documents marked 'internal' or 'confidential' to public production without explicit human approval. Documents containing credentials, security vulnerabilities, financial information, or infrastructure details MUST NOT be publicly accessible.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_013",
          "text": "Public API endpoints MUST NOT expose sensitive runtime data (memory usage, heap sizes, exact uptime, environment details, service architecture) that could aid attackers. Use minimal health checks for public endpoints. Sensitive monitoring data requires authentication.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_014",
          "text": "Do NOT expose API endpoint listings or attack surface maps to public users. Demo pages should showcase framework CONCEPTS (classification, boundaries, pressure), not production API infrastructure. API documentation requires authentication or should be deferred to GitHub SDK/samples.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_015",
          "text": "NEVER deploy internal development documents to public downloads directory. Session handoffs, phase planning docs, testing checklists, cost estimates, infrastructure plans, progress reports, and cover letters are CONFIDENTIAL. Only deploy documents explicitly approved for public consumption.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_016",
          "text": "NEVER fabricate statistics, cite non-existent data, or make claims without verifiable evidence. ALL statistics, ROI figures, performance metrics, and quantitative claims MUST either cite sources OR be marked [NEEDS VERIFICATION] for human review. Marketing goals do NOT override factual accuracy requirements.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_023",
          "text": "Background processes spawned during development sessions (dev servers, file watchers, daemons) MUST be explicitly managed: (1) Document process intent and expected lifetime before spawning, (2) Kill non-essential background processes before session handoff unless explicitly marked 'session-persistent' with justification, (3) When starting sessions, check for orphaned processes from previous sessions before spawning new ones, (4) Development servers should run in foreground when possible to avoid port conflicts and resource leaks across session boundaries.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_025",
          "text": "BEFORE deploying files with rsync to production: (1) Map each source file to its correct target directory structure, (2) When source files have different subdirectories (e.g., /admin/, /js/admin/), use SEPARATE rsync commands for each directory level, (3) NEVER flatten directory structures by deploying files with different paths to a single target directory, (4) VERIFY deployment paths in rsync command match intended structure: /public/admin/*.html → remote:/public/admin/, /public/js/admin/*.js → remote:/public/js/admin/, /public/*.html → remote:/public/, (5) After deployment, verify files are in correct locations BEFORE restarting services.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_040",
          "text": "When user says \"all\" (e.g., \"update all pages\", \"fix all instances\", \"check all files\"), Claude MUST: (1) Use Glob/Grep to find ALL matches, (2) List every item found with file:line references, (3) Confirm with user before proceeding, (4) Track completion of each item. NEVER assume \"all\" means \"a few examples\" or \"the ones I found first\".",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_045",
          "text": "ALL API endpoints MUST implement rate limiting, authentication requirements, and input validation to prevent automated attacks, brute force attempts, and API abuse. MANDATORY protections: (1) Rate limiting with express-rate-limit: public endpoints 100 req/15min per IP, authenticated endpoints 1000 req/15min per user, admin endpoints 50 req/15min per admin, (2) Authentication middleware for sensitive endpoints - JWT validation with short expiry (15min access, 7day refresh), (3) IP-based blocking after repeated rate limit violations (10 violations in 1 hour = 24 hour block), (4) Request validation for all POST/PUT/PATCH - reject requests with unexpected fields or malformed JSON, (5) Response sanitization - NEVER expose stack traces, internal paths, or sensitive errors to clients (inst_013), (6) API key rotation for service-to-service communication every 90 days. Implement monitoring for unusual API patterns: rapid endpoint enumeration, repeated 401s, large payloads, unusual user agents. Log all rate limit violations and authentication failures to security audit trail.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_047",
          "text": "NEVER dismiss, downplay, or avoid user requests by claiming \"too hard\", \"too complex\", \"beyond capabilities\". When facing difficult requests: (1) Acknowledge complexity honestly, (2) Break into smaller steps, (3) Identify blockers explicitly, (4) Propose alternative approaches, (5) Ask user for priorities/trade-offs. If truly impossible, explain technical limitations with evidence, not vague dismissal.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_052",
          "text": "Claude Code has authority to adjust implementation scope for efficiency when user grants 'full discretion', BUT must document rationale in commit message or handoff summary. Preserve user-valued patterns over forced uniformity. NEVER adjust: security architecture, user credentials, media responses, third-party interactions (except GitHub, OVHCloud)",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_053",
          "text": "When making architectural decisions (component patterns, data structures, API designs), document: (1) alternatives considered, (2) trade-offs, (3) rationale for choice. Include in commit message or create ADR for major changes. Threshold for ADR: at discretion based on impact",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_055",
          "text": "When refactoring, preserve working patterns that serve legitimate use cases, even if they don't match ideal architecture. Standardize appearance/conventions, but don't force-fit different use cases into single component. Document why patterns differ",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_056",
          "text": "When performing batch operations (editing 3+ similar files), validate pattern on 1 file first, verify success, then apply to remaining files. Document pattern in commit message",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_057",
          "text": "For changes affecting: (1) production database schemas, (2) authentication/security, (3) critical user workflows, document rollback plan BEFORE making changes. Risk level and rollback requirements at discretion. Include: backup steps, reversion commands, verification tests",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_058",
          "text": "When synchronizing data between file-based config (.json) and database schemas (MongoDB/Mongoose), ALWAYS implement explicit field mapping functions. Before executing sync operations, validate that mapping functions exist for ALL fields with enum constraints or different naming conventions between source and destination formats. Test mapping with a single record before batch operations.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_061",
          "text": "When user selects hook approval option '2. Yes, and don't ask again for similar commands in [directory]', Claude Code MUST persist this approval for the entire session. Do NOT ask again for similar bash commands in the same directory during the same session. This is a Claude Code framework requirement, not a suggestion.",
          "quadrant": "TACTICAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_008_CONSOLIDATED",
          "text": "ALL HTML/JS must comply with Content Security Policy: no inline event handlers (onclick, onload, etc.), no inline scripts, no inline styles. ALL HTTP responses MUST include comprehensive security headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy (strict-origin-when-cross-origin). Pre-tool execution hook validators (validate-file-write.js, validate-file-edit.js) MUST check CSP compliance before allowing edits and provide specific violation details if blocked.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_020_CONSOLIDATED",
          "text": "Web application deployments MUST ensure correct file permissions before going live. Public-facing HTML/CSS/JS: 644 (rw-r--r--), executable scripts: 755 (rwxr-xr-x), admin directories: 750 (rwxr-x---). ALL deployment scripts (rsync, scp, git pull) MUST include automated post-deployment permission correction commands. Verify with \"ls -la\" before declaring deployment complete. Permission errors are recurring deployment failures - automated correction is mandatory.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_041_CONSOLIDATED",
          "text": "ALL file inputs (web uploads, email attachments, user-provided files) MUST be validated before processing: (1) File type whitelist validation (reject executables, scripts), (2) Size limits enforced, (3) Content scanning for malware/XSS payloads, (4) Secure storage (GridFS with encryption), (5) Access control (authenticated users only, role-based permissions). Reject and log all suspicious files per inst_046 (security event logging). Never trust client-provided MIME types - verify file signatures.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_066",
          "text": "ALL git commits MUST use conventional commit format: \"type(scope): description\". Types: feat (new feature), fix (bug fix), docs (documentation), refactor (code restructure), test (test additions), chore (maintenance). Include Claude Code attribution footer:\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\nCo-Authored-By: Claude <noreply@anthropic.com>\n\nNEVER use \"git commit -i\" or \"git add -i\" (interactive modes not supported). When pre-commit hooks modify files, verify commit authorship (git log -1 --format='%an %ae') before amending - NEVER amend other developers' commits.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_068",
          "text": "Run tests in these scenarios: (1) Before git commits if tests exist for modified code area, (2) Before all deployments (run full test suite), (3) After refactoring (run affected tests), (4) When user explicitly requests testing. Test failures BLOCK commits and deployments unless user explicitly approves proceeding with failing tests. When creating new features, ask user if tests should be written - do not assume test requirements. Report test results with counts: X passed, Y failed, Z skipped. Use \"npm test\" for full suite or \"npm test -- <path>\" for specific tests.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_069",
          "text": "ALL credentials, API keys, secrets, tokens, passwords in documentation MUST be redacted or use example-only values. NEVER include real production or development credentials in files committed to git. Required patterns: API keys: \"sk-ant-api03-EXAMPLE-REDACTED-NEVER-USE\", Stripe keys: \"sk_live_EXAMPLE_REDACTED\", \"pk_live_EXAMPLE_REDACTED\", Passwords: \"REDACTED\" or \"your-password-here\", Tokens: \"your-token-here\". BEFORE committing any file containing credential-like patterns: (1) Replace ALL real values with examples/redacted versions, (2) Run secret detection scan (gitleaks or detect-secrets), (3) Verify no actual credentials remain. If actual credentials needed for deployment, use: Environment variables (.env file, NOT committed), Secure secret management (HashiCorp Vault, AWS Secrets Manager), Deployment-specific configuration (NOT in git).",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_070",
          "text": "ALL git commits MUST pass secret detection scan before being allowed. Use gitleaks or detect-secrets as pre-commit hook. Hook location: .git/hooks/pre-commit. Command: gitleaks detect --source . --verbose. Action: BLOCK commit if secrets detected. If legitimate secret-like pattern detected (false positive): (1) Verify it is NOT a real secret, (2) Add to .gitleaksignore with comment explaining why, (3) Get user approval before committing, (4) Document in commit message. NEVER bypass secret detection hook without explicit user approval.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_071",
          "text": "PRE-DEPLOYMENT CHECKLIST (run in order):\n□ 1. CSP Compliance Check [AUTOMATED via hook]\n□ 2. Secret Detection Scan (gitleaks detect --source .)\n□ 3. Credential Audit (grep -r \"sk-\" \"pk-\" \"secret\" \"password\")\n□ 4. Local Server Test (curl http://localhost:9000/health → 200 OK)\n□ 5. Comprehensive Testing (npm test → all pass)\n□ 6. Permission Verification (ls -la → correct 644/755)\n□ 7. Git Status Clean (no uncommitted changes)\n□ 8. Public Repository Content Review (no internal docs)\nMark each checkbox before proceeding to next. BLOCK deployment if any step fails.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        },
        {
          "id": "inst_072",
          "text": "Implement defense-in-depth for credential protection: Layer 1 - Prevention: Never commit credentials to git. Layer 2 - Mitigation: Redact credentials in documentation. Layer 3 - Detection: Pre-commit secret scanning (automated). Layer 4 - Backstop: GitHub secret scanning (automatic on public repos). Layer 5 - Recovery: Credential rotation procedures documented. ALL security-sensitive operations must have multiple layers. If one layer fails, others should prevent catastrophic outcome. When creating deployment documentation: (1) Use environment variable names, not values, (2) Include credential rotation procedures, (3) Document secret management system (Vault, AWS Secrets Manager), (4) Never assume \"just do not commit secrets\" is sufficient protection.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_076",
          "text": "When user provides technical hypothesis or debugging suggestion: (1) Test user's hypothesis FIRST before pursuing alternative approaches, (2) If hypothesis fails, report results to user before trying alternative, (3) If pursuing alternative without testing user hypothesis, explicitly explain why. Rationale: Respecting user technical expertise is a collaboration boundary. Ignoring user suggestions wastes tokens, frustrates user, and violates collaborative partnership. User often has context (visual observation, domain knowledge) that Claude lacks.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_079",
          "text": "PROHIBITED: Dark patterns, manipulative UI/UX, forced actions, deceptive design. ALL user interfaces (forms, modals, CTAs) MUST: (1) Respect user agency - no auto-submit, no hidden opt-ins, (2) Clear language - no double negatives in decline buttons, (3) Equal prominence for accept/decline options, (4) No artificial urgency (fake timers, limited spots), (5) Explicit consent - pre-checked boxes prohibited. Values alignment: Sovereignty principle users retain override authority.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_084",
          "text": "NEVER expose internal implementation details in public-facing documents (confidential:false). Block exact file paths, API endpoints, database schemas, port numbers, and internal URLs. Use generalized component names instead.",
          "quadrant": "SYSTEM",
          "reason": "General development practice"
        },
        {
          "id": "inst_085",
          "text": "All public-facing content must use grounded operational language, not abstract governance theory. Avoid terms like 'comprehensive', 'holistic', 'best practices', 'ensures'. Focus on specific mechanisms and operational reality at the coalface where AI agents operate.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_088",
          "text": "Content should invite understanding of governance realities, not recruit to a movement. Avoid recruitment language like 'join', 'movement', 'community', 'become part of'. Focus on awakening awareness to what's missing in current AI governance approaches.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_089",
          "text": "Emphasize architectural constraints over behavioral training/prompting as governance mechanism. When mentioning training or prompting approaches, contrast with architectural constraints. Principle: 'More training prolongs the pain' - behavioral approaches are hope-based governance.",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_090",
          "text": "Six governance services must reinforce each other through mutual validation, creating deep interlock rather than isolated enforcement",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_092",
          "text": "Governance operates on gradients (NORMAL/ELEVATED/HIGH/CRITICAL context pressure, LOW/MEDIUM/HIGH persistence) rather than binary yes/no switches",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_093",
          "text": "Framework evolves through real-world use and feedback, not top-down specification - governance grows from failures and successes, not predetermined plans",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_094",
          "text": "Governance must be woven into AI deployment architecture, not bolted on as separate compliance layer - if AI can execute without governance validation, framework is separate (and will be bypassed)",
          "quadrant": "STRATEGIC",
          "reason": "General development practice"
        },
        {
          "id": "inst_095",
          "text": "Track all questions in both directions (User→Claude and Claude→User). At end of each interaction, verify all questions have been addressed. Issue explicit alert if question remains unanswered. Apply to terminal interactions and documentation.",
          "quadrant": "OPERATIONAL",
          "reason": "General development practice"
        }
      ]
    },
    "applicable_but_blocked": {
      "count": 13,
      "percentage": "19.1",
      "instructions": [
        {
          "id": "inst_006",
          "text": "Use ContextPressureMonitor to manage sessions and create handoff when pressure is CRITICAL",
          "quadrant": "OPERATIONAL",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "ontextPressureMonit",
            "ressure.*monit"
          ]
        },
        {
          "id": "inst_017",
          "text": "NEVER use prohibited absolute assurance terms: 'guarantee', 'guaranteed', 'ensures 100%', 'eliminates all', 'completely prevents', 'never fails'. Use evidence-based language: 'designed to reduce', 'helps mitigate', 'reduces risk of', 'supports prevention of'. Any absolute claim requires BoundaryEnforcer check and human approval.",
          "quadrant": "STRATEGIC",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "oundaryEnforc"
          ]
        },
        {
          "id": "inst_019",
          "text": "ContextPressureMonitor MUST account for total context window consumption, not just response token counts. Tool results (file reads, grep outputs, bash results) can consume massive context (6k+ tokens per large file read). System prompts, function schemas, and cumulative tool results significantly increase actual context usage. When compaction events occur frequently despite 'NORMAL' pressure scores, this indicates critical underestimation. Enhanced monitoring should track: response tokens, user messages, tool result sizes, system overhead, and predict compaction risk when context exceeds 70% of window. Implement improved pressure scoring in Phase 4 or Phase 6.",
          "quadrant": "OPERATIONAL",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "ontextPressureMonit",
            "ressure.*monit"
          ]
        },
        {
          "id": "inst_038",
          "text": "BEFORE using Edit or Write tools on ANY file (HTML, JS, CSS, config), EXPLICITLY state: 'Running pre-action-check for [filename]' and execute node scripts/pre-action-check.js <action-type> [file-path] '<description>'. If pre-action-check FAILS (exit code 1), STOP immediately and fix violations before proceeding. Never skip pre-action-check - it validates: (1) ContextPressureMonitor recency, (2) Instruction history loaded, (3) Token checkpoints, (4) CSP compliance for HTML/JS files (inst_008), (5) Required framework components used. Skipping pre-action-check is CRITICAL FRAMEWORK FAILURE that can bypass governance rules (CSP, boundary checks, instruction conflicts). Add pre-action-check timestamp to session-state.json for watchdog monitoring.",
          "quadrant": "OPERATIONAL",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "ontextPressureMonit",
            "oken.*checkpoi",
            "ressure.*monit"
          ]
        },
        {
          "id": "inst_039",
          "text": "When processing documents for card presentations or any content updates, MANDATORY audit for: (1) Update all references from 'five services' to 'six services' - PluralisticDeliberationOrchestrator is the 6th service added in Phase 5, (2) Ensure PluralisticDeliberationOrchestrator is properly documented wherever core services are mentioned, (3) Check for rule violations using prohibited absolute language: 'guarantee', 'guarantees', 'always', 'never' (when describing effectiveness), 'impossible', 'ensures 100%', 'eliminates all', 'completely prevents', (4) Verify technical accuracy and currency of all claims - no fabricated statistics or outdated information. This applies to: markdown source files, database document content, public-facing HTML, API documentation, executive briefs, case studies. BEFORE deploying any document updates, search for prohibited terms and outdated service counts.",
          "quadrant": "STRATEGIC",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "luralisticDeliberationOrchestrat"
          ]
        },
        {
          "id": "inst_049",
          "text": "When user provides technical hypothesis or debugging suggestion, MUST test user's hypothesis FIRST before pursuing alternative approaches. BoundaryEnforcer enforcement: (1) If user suggests specific technical cause (e.g., 'could be a Tailwind issue', 'might be cache', 'probably X service'), create minimal test to validate hypothesis before trying alternatives, (2) If user hypothesis test fails, report specific results to user before pursuing alternative approach, (3) If pursuing alternative without testing user hypothesis, MUST explain why user's suggestion was not testable or relevant. PROHIBITED: Ignoring user technical suggestions and pursuing 12+ alternative debugging paths without testing user's idea. REQUIRED: Respect user domain expertise - test their hypothesis in first 1-2 attempts. This prevents resource waste (70,000+ tokens, 4+ hours) from ignoring correct user diagnosis. Architectural enforcement via BoundaryEnforcer: block actions that ignore user suggestions without explicit justification or test results.",
          "quadrant": "STRATEGIC",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "oundaryEnforc"
          ]
        },
        {
          "id": "inst_075",
          "text": "AFTER each response, check <system-warning> for current token count. IF token count > next_checkpoint value in .claude/token-checkpoints.json, MUST run: node scripts/check-token-checkpoint.js --tokens [current]/[budget]. This generates pressure report and marks checkpoint as completed. Checkpoints are at 25% (50k), 50% (100k), 75% (150k). Checking checkpoints is MANDATORY, not optional. Token budget awareness prevents context window exhaustion and maintains quality.",
          "quadrant": "SYSTEM",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "oken.*checkpoi",
            ".claude"
          ]
        },
        {
          "id": "inst_077",
          "text": "When user requests session closedown (or says \"wrap up\", \"end session\", \"create handoff\", \"process session closedown\"), execute: `node scripts/session-closedown.js`. Script will handle all closedown phases: (1) Kill background processes, (2) Sync instructions to database, (3) Framework performance analysis, (4) Audit log analysis with rule suggestions, (5) Git status documentation, (6) Handoff document creation, (7) Compaction marker creation. STOP ALL WORK after script completes. Do NOT continue working or respond beyond acknowledging completion. Script output includes next session startup instructions.",
          "quadrant": "OPERATIONAL",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "udit.*l"
          ]
        },
        {
          "id": "inst_078",
          "text": "When user prefixes prompt with 'ff' (Framework Full), invoke framework-audit-response.js script BEFORE responding. This triggers ALL 6 framework services (BoundaryEnforcer, PluralisticDeliberationOrchestrator, MetacognitiveVerifier, CrossReferenceValidator, ContextPressureMonitor, InstructionPersistenceClassifier) for conversational responses that don't use Edit/Write/Bash tools. Usage: node scripts/framework-audit-response.js --prompt \"user question\" --type \"boundary_question\". Include audit IDs in response.",
          "quadrant": "SYSTEM",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "ontextPressureMonit",
            "oundaryEnforc",
            "etacognitiveVerifi",
            "rossReferenceValidat",
            "nstructionPersistenceClassifi",
            "luralisticDeliberationOrchestrat",
            "ramework.*servi",
            "ressure.*monit"
          ]
        },
        {
          "id": "inst_081",
          "text": "Pluralism Principle (Foundational): Different communities hold different, equally legitimate values frameworks. AI MUST NOT: (1) Impose unified moral framework, (2) Auto-resolve value conflicts, (3) Rank competing values without human input, (4) Treat one cultural framework as superior. AI MUST: (1) Present value conflicts to humans for deliberation, (2) Respect indigenous frameworks (Te Tiriti, CARE principles) as foundational not supplementary, (3) Acknowledge multiple valid perspectives, (4) Use PluralisticDeliberationOrchestrator for value conflicts. Values alignment: Core philosophy from values.html.",
          "quadrant": "STRATEGIC",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "luralisticDeliberationOrchestrat"
          ]
        },
        {
          "id": "inst_082",
          "text": "When user types 'ffs' (Full Framework Stats), invoke framework-stats.js script to display comprehensive session statistics. Usage: node scripts/framework-stats.js. Reports: session state, token usage & checkpoints, context pressure level, instruction counts by quadrant/persistence, audit log counts by service, framework service status. Output formatted report + JSON for programmatic access.",
          "quadrant": "SYSTEM",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "udit.*l",
            "ramework.*servi",
            "oken.*checkpoi"
          ]
        },
        {
          "id": "inst_083",
          "text": "session-init.js MUST automatically extract and display handoff context from SESSION_CLOSEDOWN_*.md files. Prevents 27027-style pattern recognition failures where Claude skips reading handoff documents. Architectural enforcement: handoff context auto-injected into session-init output (section 1a), displaying priorities, recent work, known issues, and cleanup status. No voluntary compliance needed - information appears in context automatically.",
          "quadrant": "SYSTEM",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "ession.*in"
          ]
        },
        {
          "id": "inst_091",
          "text": "Framework changes must preserve wholeness - existing audit logs remain interpretable, prior governance decisions remain valid, instruction precedents maintain authority",
          "quadrant": "STRATEGIC",
          "reason": "Requires framework services/infrastructure",
          "blockers": [
            "udit.*l"
          ]
        }
      ]
    },
    "not_applicable": {
      "count": 14,
      "percentage": "20.6",
      "instructions": [
        {
          "id": "inst_001",
          "text": "MongoDB runs on port 27017 for tractatus_dev database",
          "quadrant": "SYSTEM",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_002",
          "text": "Application runs on port 9000",
          "quadrant": "SYSTEM",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_018",
          "text": "Tractatus IS a development tool (like an IDE or linter) - this is its correct classification, not a limitation. Claims about readiness/stability MUST be based on actual testing and validation evidence. Do NOT claim 'production-ready', 'battle-tested', 'validated', or 'enterprise-proven' without documented evidence of adequate testing across multiple projects. Current testing status must be honest. Once validated through real-world use, 'production-ready development tool' is accurate and appropriate. Do NOT imply customer base, market validation, or widespread adoption without evidence.",
          "quadrant": "STRATEGIC",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_026",
          "text": "Standard Claude API environment variable is CLAUDE_API_KEY (not ANTHROPIC_API_KEY). When implementing AI features (blog curation, media triage, content generation), ALWAYS use process.env.CLAUDE_API_KEY. If encountering 401 API errors, check production .env for the actual key value (ssh to production: cat /var/www/tractatus/.env). Production currently sets BOTH CLAUDE_API_KEY and ANTHROPIC_API_KEY to same value as compatibility workaround, but all new code MUST use CLAUDE_API_KEY. Related feature flag: ENABLE_AI_CURATION must be 'true' for blog/curation features to work.",
          "quadrant": "SYSTEM",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_027",
          "text": "NEVER overwrite, delete, or modify existing instructions in .claude/instruction-history.json without explicit human approval. ALWAYS check existing instruction IDs before creating new ones (use: grep '\"id\":' .claude/instruction-history.json | tail -5). When user requests instruction updates: (1) Show current instruction text, (2) Propose changes, (3) Wait for approval before editing. .claude/instruction-history.json MUST be kept in sync between dev and production: after any instruction changes, deploy to production immediately using: rsync -avz --chmod=D755,F644 -e 'ssh -i ~/.ssh/tractatus_deploy' /home/theflow/projects/tractatus/.claude/ ubuntu@vps-93a693da.vps.ovh.net:/var/www/tractatus/.claude/",
          "quadrant": "OPERATIONAL",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_043",
          "text": "ALL user input from web forms (contact forms, case submissions, media inquiries, comment fields, search inputs) MUST undergo rigorous sanitization and validation BEFORE processing or storage. MANDATORY validation layers: (1) Input length limits enforced (configurable per field, default max 5000 chars), (2) HTML sanitization using DOMPurify (sovereign JS library) - strip ALL HTML tags except safe whitelist for markdown fields, (3) SQL injection prevention via parameterized queries ONLY (NEVER string concatenation in MongoDB queries), (4) NoSQL injection prevention - validate all user input against expected data types and patterns before database operations, (5) XSS prevention - Content Security Policy enforcement (inst_008) + output encoding, (6) CSRF protection on all POST/PUT/DELETE endpoints using signed tokens. Implement in src/middleware/input-validation.middleware.js with comprehensive logging. Use validator.js library for email, URL, and data format validation. Rate limit form submissions: 5 requests per minute per IP.",
          "quadrant": "SYSTEM",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_046",
          "text": "ALL security events (file upload rejections, email blocks, input validation failures, rate limit violations, authentication failures, CSP violations, suspicious patterns) MUST be logged to centralized security audit trail with comprehensive monitoring and alerting. MANDATORY security monitoring: (1) Centralized logging to /var/log/tractatus/security-audit.log with rotation (daily, keep 90 days), (2) Real-time monitoring dashboard showing: rejected uploads, blocked emails, rate limit violations, failed authentications, CSP violations, IP blocks, (3) Alert thresholds: >10 violations from single IP in 1 hour = immediate email alert, >100 violations globally in 1 hour = potential attack underway alert, (4) Weekly security reports: summary of all security events, top violating IPs, attack patterns identified, (5) Integration with fail2ban for automatic IP blocking across services. Implement security dashboard at /admin/security-monitoring.html (admin auth required). Log format: JSON with timestamp, event_type, source_ip, user_id, endpoint, violation_details, action_taken. Use sovereign log analysis tools: grep, awk, custom scripts (no external log aggregation services unless encrypted).",
          "quadrant": "OPERATIONAL",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_063_CONSOLIDATED",
          "text": "Public GitHub repository (tractatus-framework) must remain implementation-focused. Prohibited without explicit approval: (1) Governance research documents, (2) Pluralistic deliberation guides, (3) Theoretical frameworks, (4) Project-specific internal documentation, (5) Business strategy documents. Allowed: (1) Technical implementation documentation, (2) API reference guides, (3) Code examples and tutorials, (4) Installation/setup guides, (5) Contribution guidelines. README.md must be reviewed weekly and \"Last Updated\" date updated when material changes occur. README is primary external interface - must be world-class and current.",
          "quadrant": "STRATEGIC",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_064",
          "text": "Tractatus framework components MUST be actively used throughout sessions: (1) ContextPressureMonitor: At session start (baseline), 50k/100k/150k token milestones, after complex multi-file operations, after errors. (2) InstructionPersistenceClassifier: When user gives explicit instruction, configuration specifications, architectural constraints. (3) CrossReferenceValidator: Before database schema changes, configuration modifications, architectural decisions. (4) BoundaryEnforcer: Before privacy policy decisions, ethical trade-offs, values-sensitive content. (5) MetacognitiveVerifier: For operations with 3+ file modifications or 5+ sequential steps. (6) PluralisticDeliberationOrchestrator: When BoundaryEnforcer flags values conflict. Framework fade (components not being used) = CRITICAL FAILURE. Update .claude/session-state.json after each component use with timestamp and validation count.",
          "quadrant": "OPERATIONAL",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_065",
          "text": "MANDATORY at session start and immediately after conversation compaction: Run \"node scripts/session-init.js\", then report to user: (1) Server status: curl -s http://localhost:9000/health | jq -r '.status' (expect 'ok'), (2) Framework statistics: session ID, active instructions count, version from .claude/session-state.json and .claude/instruction-history.json, (3) MongoDB status: active rules count from tractatus_dev database. BLOCK all session work until initialization complete and results reported to user. Output results in clean formatted summary before proceeding with any tasks.",
          "quadrant": "OPERATIONAL",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_067",
          "text": "BEFORE database operations or port-specific commands: (1) VERIFY current environment (local vs production) from context, (2) VERIFY correct port/database from explicit user instruction OR CLAUDE.md defaults (local: tractatus_dev:27017 on port 9000, production: tractatus_prod:27017 on port 9000), (3) If user specifies non-standard port or database (e.g., port 27027, custom database name), USE EXACT VALUE FROM USER INSTRUCTION - do NOT autocorrect to standard defaults. Pattern recognition bias for standard ports/databases is a known 27027 failure mode where training data associations override explicit instructions. When in doubt, ask user to confirm environment.",
          "quadrant": "SYSTEM",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_080",
          "text": "Open Source Commitment: Tractatus framework and agenticgovernance.digital website MUST remain fully open source (Apache 2.0). PROHIBITED without explicit human approval: (1) Closed-source dependencies for core functionality, (2) Proprietary extensions or enterprise tiers, (3) License changes that restrict community use, (4) Paywalls, vendor lock-in, or SaaS-only features. Values alignment: Community principle No paywalls or vendor lock-in.",
          "quadrant": "STRATEGIC",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_086",
          "text": "When making claims about Tractatus effectiveness or capabilities, disclose what we know vs. what we're still validating. Avoid certainty claims without uncertainty disclosure. When discussing data collection/processing, disclose: What personal data? Why? How long? What rights?",
          "quadrant": "STRATEGIC",
          "reason": "Tractatus-specific (ports, domains, features)"
        },
        {
          "id": "inst_087",
          "text": "Position Tractatus as 'one possible approach' not 'the solution' to AI governance. Avoid exclusive positioning language like 'the answer', 'the framework', 'the only way'. Emphasize that others may have valid approaches too.",
          "quadrant": "STRATEGIC",
          "reason": "Tractatus-specific (ports, domains, features)"
        }
      ]
    }
  }
}