Summary

Four architectural changes to the harness: replaced Claude’s self-assessed state transitions with a deterministic state machine driven by project metrics, added CCCS quality gates (Completeness, Consistency, Correctness, Stability), introduced a red team adversarial review agent, and restructured the scaffold flow with stakeholder identification and roleplay-based requirements elicitation.

Changes

1. Deterministic state machine

Problem: Claude failed to transition state correctly three times — the stuck decompose loop (sessions 360–374), premature first-pass-complete on a 28-requirement project (air traffic control), and a mid-QC state override (session 376). All three failures stemmed from Claude setting FLOW_STATE incorrectly or at the wrong time.

Fix: State transitions are now computed by the harness from project metrics via guard functions. Claude no longer sets FLOW_STATE. The flow engine applies the transition’s target state after each session, and guard functions evaluate whether a forward transition should occur before the next session starts.

All FLOW_STATE upsert instructions removed from all five flow files. Claude focuses on engineering work; the harness handles progression.

2. CCCS quality gates

The three quality gate guards (isFirstPassComplete, isQCPassed, isValidated) now evaluate four dimensions:

Completeness: Missing rationale, missing verification, unassigned document requirements, orphan count, STK/SUB/IFC/VER requirement counts.

Consistency: High-severity lint findings (from airgen lint --min-severity high).

Correctness: Ambiguous requirement text detected by keyword scan ({appropriate, sufficient, adequate, reasonable, timely, user-friendly, robust, flexible, normal, proper, good, fast, slow}).

Stability: Requirement churn rate measured by sampling 30 requirements via airgen reqs history — percentage with >1 version (edited more than once).

Gate	Key Thresholds
isFirstPassComplete	≥8 STK, ≥80 SUB, ≥20 IFC, ≥3 diagrams, ≥10 sessions, ≤5 missing fields, 0 unassigned docs
isQCPassed	≤5 orphans, ≥70% VER/IFC, ≤3 lint high, ≤10 ambiguous reqs
isValidated	0 orphans, 0 missing fields, ≥200 reqs, ≥90% VER/IFC, 0 lint high, ≤3 ambiguous, ≤20% churn

Each guard logs its evaluation with specific blockers for operator visibility.

3. Red team review agent (Flow F)

New flow SE_REDTEAM runs automatically after a system is marked complete, before the loop picks the next system. Seven adversarial checks:

1. Failure mode coverage — subsystems without fault/failure/degradation requirements
2. Testability audit — ISO 29148 measurability via airgen quality analyze
3. Domain gap search — cross-domain analogs surfacing missing requirement categories
4. Interface plausibility — IFC requirements without protocol/rate/latency specs
5. Proportion analysis — under/over-specified subsystems
6. Trace chain brittleness — mechanical derivation links without engineering rationale
7. Implausibility scan — round values, template text, placeholder patterns

Findings tagged with rt- prefix on requirements (rt-untestable, rt-missing-failure-mode, rt-implausible-value, rt-vague-interface, rt-mechanical-trace). Holistic findings stored as RED_TEAM_FINDING facts in QUALITY namespace. The red team does not modify requirements — it flags them.

4. Stakeholder roleplay in scaffold flow

Scaffold flow step 10 expanded from “minimum 3 STK requirements” to a structured three-phase stakeholder process:

10a. Identify stakeholders — map all roles across the full system lifecycle: operators, end users/beneficiaries, maintainers, regulators (with specific standards), procurers, adjacent system operators, safety authorities, training staff. Each stored as a HAS_STAKEHOLDER Substrate fact.

10b. Roleplay each stakeholder — adopt each stakeholder’s perspective to generate requirements from their viewpoint. At least 2 STK requirements per stakeholder. Rationale must name the stakeholder and explain what drives the need from their perspective. Tagged with stk-<stakeholder-slug> for per-stakeholder traceability.

10c. Cross-check coverage — verify every identified stakeholder has requirements, regulatory stakeholders cite specific standards, conflicting needs documented as ARC decisions.

Version manifest

Component	Before	After
State transitions	Claude sets FLOW_STATE	Guards compute from project metrics
Quality gates	Count-only (reqs, orphans)	CCCS: completeness + consistency + correctness + stability
Stability metric	Baseline count	Requirement history churn (sampled)
Red team	None	Flow F: 7 adversarial checks after completion
Stakeholder phase	”Minimum 3 STK”	Identify → roleplay → cross-check (≥2 per stakeholder)
STK gate	None	≥8 STK requirements for first-pass-complete
Flows	5 (A–E)	6 (A–F, +red-team)
Git commits	4	9