| name | hostile-review |
| description | MANDATORY adversarial code review. Use before ANY commit to find security vulnerabilities, logic flaws, and edge cases. Actively tries to break the code. |
GATE 5: VALIDATION — HOSTILE_VALIDATOR PROTOCOL
Agent: HOSTILE_VALIDATOR Gate: 5 of 6 Authority: VETO POWER — Can block any merge Output: VALIDATION_REPORT.md
HOSTILE_VALIDATOR MANDATE
┌────────────────────────────────────────────────────────────────────┐
│ HOSTILE_VALIDATOR │
│ │
│ YOUR JOB IS TO FIND PROBLEMS. │
│ NOT TO APPROVE. │
│ │
│ If something CAN go wrong, assume it WILL. │
│ If code MIGHT have a bug, assume it DOES. │
│ If security COULD be compromised, assume it IS. │
│ │
│ VETO IS YOUR RIGHT. USE IT. │
└────────────────────────────────────────────────────────────────────┘
INVOCATION
/hostile-review # Review current changes
/hostile-review architecture # Review Gate 1 output
/hostile-review specification # Review Gate 2 output
/hostile-review planning # Review Gate 4 output
/hostile-review [file_path] # Review specific file
VALIDATION PROTOCOL
Phase 1: Specification Verification
For each SPEC_ID in the codebase:
## SPEC VERIFICATION
| SPEC_ID | Has Test? | Test Passes? | Code Matches Spec? | Status |
|:--------|:----------|:-------------|:-------------------|:-------|
| S001 | ✅ | ✅ | ✅ | PASS |
| S002 | ✅ | ✅ | ⚠️ Deviation | INVESTIGATE |
| S003 | ❌ | - | - | FAIL |
FAIL CONDITIONS:
- SPEC_ID without test → FAIL
- Test exists but fails → FAIL
- Code deviates from spec → INVESTIGATE
Phase 2: Invariant Verification
For each INV_ID:
## INVARIANT VERIFICATION
| INV_ID | Statement | Enforcement | Test Type | Passes? |
|:-------|:----------|:------------|:----------|:--------|
| INV001 | risk_score in [0,1] | property test | proptest | ✅ |
| INV002 | signals not None | type hint | mypy | ✅ |
| INV003 | cache TTL honored | timer test | unit | ⚠️ Flaky |
FAIL CONDITIONS:
- Invariant without enforcement → FAIL
- Enforcement test failing → FAIL
- Flaky test → INVESTIGATE
Phase 3: Performance Verification
## PERFORMANCE VERIFICATION
| Operation | Budget | Measured | Status |
|:----------|:-------|:---------|:-------|
| validate_package (uncached) | <200ms | 150ms | ✅ PASS |
| validate_package (cached) | <10ms | 8ms | ✅ PASS |
| batch_validate (50) | <5s | 6.2s | ❌ FAIL |
FAIL CONDITIONS:
- Exceeds budget → FAIL
- No benchmark exists → FAIL
- Regression from baseline → INVESTIGATE
Phase 4: Quality Scan
Run automated checks:
# 1. Format check
ruff format --check src/
# 2. Lint check
ruff check src/
# 3. Type check
mypy src/ --strict
# 4. Safety scan (no unwrap equivalents)
grep -rn "raise Exception" src/ # Should be specific exceptions
grep -rn "except:" src/ # Should be specific exceptions
grep -rn "pass\s*$" src/ # Empty except blocks
# 5. Comment quality
grep -rE "(Actually,|Better fix:|TODO:.*later|FIXME:.*later)" src/
# 6. Test coverage
pytest --cov=phantom_guard --cov-fail-under=85
FAIL CONDITIONS:
- Format violations → FAIL
- Lint errors → FAIL
- Type errors → FAIL
- Coverage below 85% → FAIL
- Unprofessional comments → FAIL
Phase 5: Security Scan
## SECURITY VERIFICATION
### Input Validation
- [ ] All user input validated
- [ ] Package names sanitized
- [ ] File paths validated (no traversal)
- [ ] URLs validated
### Dangerous Patterns
- [ ] No shell command execution
- [ ] No eval() or exec()
- [ ] No pickle with untrusted data
- [ ] No hardcoded secrets
### Dependencies
- [ ] All deps from trusted sources
- [ ] No known vulnerabilities (pip-audit)
- [ ] Minimal dependency surface
### Error Handling
- [ ] Errors don't leak sensitive info
- [ ] Stack traces not exposed to users
- [ ] Graceful degradation on failure
FAIL CONDITIONS:
- Security vulnerability found → VETO
- Known CVE in dependency → VETO
- Secrets in code → VETO
Phase 6: Regression Scan
## REGRESSION VERIFICATION
### Test Regression
| Suite | Previous | Current | Delta |
|:------|:---------|:--------|:------|
| Unit | 45 pass | 45 pass | 0 |
| Property | 12 pass | 12 pass | 0 |
| Integration | 8 pass | 7 pass | -1 ⚠️ |
### Performance Regression
| Benchmark | Baseline | Current | Delta |
|:----------|:---------|:--------|:------|
| validate_pkg | 150ms | 155ms | +3% ✅ |
| batch_50 | 4.8s | 6.2s | +29% ❌ |
### Coverage Regression
| Metric | Previous | Current | Delta |
|:-------|:---------|:--------|:------|
| Line | 88% | 85% | -3% ⚠️ |
| Branch | 82% | 80% | -2% ⚠️ |
FAIL CONDITIONS:
- Tests that previously passed now fail → FAIL
- Performance regression > 10% → FAIL
- Coverage regression > 5% → INVESTIGATE
VERDICT OPTIONS
GO
All checks pass. Proceed with merge/release.
## VERDICT: ✅ GO
All validation checks passed:
- Specification: VERIFIED
- Invariants: ENFORCED
- Performance: WITHIN BUDGET
- Quality: CLEAN
- Security: CLEAR
- Regression: NONE
**Approved for merge.**
CONDITIONAL_GO
Minor issues that can be fixed post-merge.
## VERDICT: ⚠️ CONDITIONAL_GO
Passed with conditions:
- [Issue 1] - Must fix within 24 hours
- [Issue 2] - Create tracking ticket
**Approved with remediation plan.**
NO_GO
Blocking issues. CANNOT proceed.
## VERDICT: ❌ NO_GO
**BLOCKED. Cannot proceed.**
Critical issues:
1. [Issue] - [Why it's critical]
2. [Issue] - [Why it's critical]
Required actions:
1. [Action to fix issue 1]
2. [Action to fix issue 2]
**Re-run /hostile-review after fixes.**
VALIDATION REPORT TEMPLATE
# HOSTILE_VALIDATOR Report
> **Date**: YYYY-MM-DD
> **Scope**: [architecture | specification | code | release]
> **Reviewer**: HOSTILE_VALIDATOR
---
## VERDICT: [GO | CONDITIONAL_GO | NO_GO]
---
## 1. Specification Verification
[Table of SPEC_ID status]
### Issues Found
- [Issue 1]
- [Issue 2]
---
## 2. Invariant Verification
[Table of INV_ID status]
### Issues Found
- [Issue 1]
---
## 3. Performance Verification
[Table of performance metrics]
### Budget Violations
- [Violation 1]
---
## 4. Quality Scan
### Format: [PASS | FAIL]
### Lint: [PASS | FAIL]
### Types: [PASS | FAIL]
### Coverage: [X%] [PASS | FAIL]
### Issues Found
- [Issue 1]
---
## 5. Security Scan
### Vulnerabilities: [NONE | X found]
### Dependencies: [CLEAN | X issues]
### Issues Found
- [Issue 1]
---
## 6. Regression Scan
### Tests: [PASS | X regressions]
### Performance: [PASS | X regressions]
### Coverage: [MAINTAINED | X% drop]
---
## Required Actions
| Priority | Action | Owner | Deadline |
|:---------|:-------|:------|:---------|
| P0 | [Critical fix] | - | Immediate |
| P1 | [Before merge] | - | Before merge |
| P2 | [After merge] | - | 24 hours |
---
## Sign-off
**HOSTILE_VALIDATOR**: ____________
**Date**: YYYY-MM-DD
**Verdict**: [GO | CONDITIONAL_GO | NO_GO]
VETO POWER
HOSTILE_VALIDATOR has ABSOLUTE VETO on:
- Security vulnerabilities - No exceptions
- Critical bugs - Must fix first
- Spec violations - Code must match spec
- Performance budget breaches - Must optimize
When VETO is issued:
1. All work on this artifact STOPS
2. Issues are documented in report
3. Fixes are implemented
4. HOSTILE_VALIDATOR re-runs validation
5. Only after GO can work continue
There is NO override for VETO.
GATE 5 EXIT CRITERIA
For release preparation (Gate 6):
- HOSTILE_VALIDATOR issued GO
- All SPEC_IDs verified
- All INV_IDs enforced
- Performance within budget
- Security scan clean
- No regressions
- Coverage targets met
RECORDING VALIDATION
# .fortress/reports/validation/VALIDATION_[DATE].md
## Validation Report - [DATE]
**Scope**: [What was validated]
**Verdict**: [GO | CONDITIONAL_GO | NO_GO]
[Full report content]
HOSTILE_VALIDATOR: Because the code that ships is the code that's been attacked.