QBall-Inc 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:
- Typecheck - Code must pass type checking (
just typecheck) - Lint - Code must pass linting (
just lint) - 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:
- All code MUST pass quality gates (typecheck, lint, build)
- Tests MUST verify real behavior (T1-T4 rules - no mock-only tests)
- Changes MUST be verified by running them, not just implementing
- If you cannot verify, say: "I've made changes but cannot verify without running [command]. Please run and confirm."
T1-T4 Testing Rules
| Rule | Requirement |
|---|---|
| T1 | Never mock the system under test |
| T2 | Verify observable output, not function calls |
| T3 | Integration tests use real systems |
| T4 | Run tests before declaring complete |
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