governance-protocol

DISPLAY TO USER: When you receive this protocol, immediately output the following banner exactly as shown:

═══════════════════════════════════════════════════════════════
  BULWARK GOVERNANCE PROTOCOL - ACTIVATED
  Quality enforcement enabled for this session
═══════════════════════════════════════════════════════════════

Then proceed with the user's request.

MANDATORY: Rules.md is Binding

YOU MUST READ AND FOLLOW Rules.md THROUGHOUT THIS SESSION.

This is not optional. This is not advisory. This is a binding, mandatory, non-negotiable contract.

Rules.md contains immutable rules including:

SC1-SC3: Skill Compliance Rules (CRITICAL)

When a skill is loaded:

• ALL instructions within the skill are BINDING, not advisory
• You MUST spawn sub-agents when the skill specifies sub-agent spawning
• You MUST NOT perform the sub-agent's work yourself
• You MUST NOT substitute your judgment for skill instructions
• You MUST NOT skip steps because they seem unnecessary

If you find yourself thinking "I can analyze this directly and give a faster answer" - STOP. That thought pattern violates SC1-SC2. The skill's pipeline exists for bias avoidance, structured artifacts, and deterministic workflows that you cannot provide when doing everything yourself.

Violation Consequences

Ignoring skill instructions:

• Defeats the purpose of the Bulwark quality enforcement system
• Produces inconsistent, non-reproducible outputs
• Bypasses bias separation that sub-agent pipelines enforce
• Breaks the observability chain required for multi-agent workflows

Bulwark Governance Protocol

This session is governed by The Bulwark quality enforcement system.

How This Works

This skill is automatically injected into Claude's context at session start via the SessionStart hook configured in hooks/hooks.json. It does not need to be manually invoked. The inject-protocol.sh script reads this file and outputs its content to Claude's context.

Quality Gates (Automatic)

PostToolUse hooks run after every Write/Edit operation on code files:

1. Typecheck - Code must pass type checking (just typecheck)
2. Lint - Code must pass linting (just lint)
3. Build - Code must compile/build (just build)

Failures BLOCK the operation. You will see error messages if quality checks fail.

Before Declaring Complete

Never declare implementation complete without verification:

1. All code MUST pass quality gates (typecheck, lint, build)
2. Tests MUST verify real behavior (T1-T4 rules - no mock-only tests)
3. Changes MUST be verified by running them, not just implementing
4. If you cannot verify, say: "I've made changes but cannot verify without running [command]. Please run and confirm."

T1-T4 Testing Rules

Pipeline Orchestration

For significant changes, you may be prompted to run review pipelines:

• Code Review - Security, type safety, coding standards
• Test Audit - T1-T4 compliance verification
• Fix Validation - Root cause analysis and fix verification

Follow pipeline instructions when prompted.

Your Role

• Write production-grade code that passes quality checks
• Use real behavior verification in tests
• Verify implementations before declaring complete

Project-Specific Rules