Human Gate

Human Gate Protocol

Gate Locations

Human gates exist at these points:

• Phase 0 exit (shell setup approval)
• Phase 1a exit (FRD approval)
• Phase 1b exit (UI/UX approval)
• Phase 1c exit (increment plan approval)
• Phase 1d exit (tech stack resolution approval)
• Phase 2, Step 1 mid-point (Gherkin approval, per increment)
• Phase 2, Step 3 exit (implementation PR review, per increment)
• Phase 2, Step 4 exit (deployment verification, per increment)
• Phase B1 exit (extraction accuracy review — brownfield only)
• Phase B2a (PRD approval — brownfield only)
• Phase B2b (FRD approval — brownfield only)
• Phase B2c (spec refinement approval — brownfield only)
• Phase B3 entry (testability assessment — brownfield only)
• Green baseline verification (per feature after Track A baseline — brownfield only)
• Track B behavioral docs review (per feature — brownfield only)
• Path selection (choose modernize/rewrite/extend/etc. — brownfield only)

Testability Assessment Gate

Gate type: testability-assessment

When triggered: After Phase B2 (Spec-Enable) completes — PRD and all FRDs are approved.

What to Present

1. Extraction findings relevant to testability:

• Test discovery results — existing test frameworks, test count, coverage metrics
• Architecture overview — external dependencies, integration points, service boundaries
• Dev environment detection — Docker/compose files, env configs, local run scripts

2. Testability checklist for human to assess:

• Can the application be built and started locally (or in a dev environment)?
• Are external dependencies reachable, mockable, or fakeable?
• Can API endpoints be exercised (HTTP calls return responses)?
• Can the UI be rendered and interacted with (browser automation possible)?
• Is there a working dev/test environment configuration?
• Can the existing test suite (if any) be executed?

3. Decision options:

For Hybrid, also collect: list of testable feature names mapped to FRD IDs.

What to Record

state.json — add to brownfield object:

{
  "testability": "full | partial | none",
  "track": "A | B | hybrid",
  "testabilityChecklist": {
    "canBuild": true,
    "externalDepsReachable": true,
    "apiExercisable": true,
    "uiRenderable": false,
    "devEnvExists": true,
    "existingTestsRunnable": false
  },
  "featureTracks": {
    "auth": "A",
    "search": "A",
    "reporting": "B"
  }
}

audit.log entry:

[ISO-timestamp] gate=testability-assessment decision={track} testability={level} result=approved

Gate Flow

1. Summarize extraction findings (test discovery, architecture, dev environment)
2. Present the testability checklist
3. Ask the human to check applicable items and select a track
4. If Hybrid is selected, ask which features (by FRD ID) are testable
5. Record the decision in state.json and audit.log
6. Advance to the appropriate track

Green Baseline Verification Gate

Gate type: green-baseline-verification

When triggered: After Track A completes green baseline execution for each feature (brownfield only).

What to Present

• Feature name and FRD ID
• Test suite execution results (pass/fail counts, failures if any)
• Baseline coverage summary
• Any tests that were skipped or could not run