gate-check

name	gate-check
description	Final quality gate before reporting task completion (Gate 3). Fills confidence assessment, runs supplementary verification for <95% items, completes self-check checklist. Writes PASS/FAIL result to subtask.md, then calls autoworker:dispatch for routing.

autoworker:gate-check — Pre-Completion Self-Check (Gate 3)

Trigger: Called by autoworker:dispatch when all tests are complete. Pure assessment skill — does not make routing decisions.

Execution Flow

1. Pre-Check

Glob `subtask_*.md` (exclude subtask_template.md) →
  0 found → stop, prompt to create subtask
  1 found → use directly (backward compatible)
  multiple → grep `status:` to filter:
    - Files without status field treated as active (backward compatible)
    - Exactly 1 active → use it
    - 0 active → list all files + status, prompt user to choose
    - >1 active → report anomaly
→ Read → check "Test Results" section

• Test results section is empty → FAIL, prompt to complete tests and call autoworker:checkpoint first
• Has test results → continue

1.5. Acceptance Criteria Traceability

Read subtask's "Acceptance Criteria" table, check whether each metric was measured in L1-L4 test results:

• Metric not measured → that change point's confidence < 95% (Step 3 will trigger supplementary verification)
• All metrics have corresponding test results → continue
• No acceptance criteria table (legacy subtask format) → skip this step

2. Fill Confidence Assessment Table

In subtask.md's "Confidence Assessment" section, fill in for each change point:

Change point	Test level	Confidence	Verification method	Unverified/Risk

Confidence inference basis:

• Has L4 pass + meaningful output → 95%+
• Has L2 but no L4 → 70-85%
• Only L1 → 50-70%
• Untested → 30%

3. Supplementary Verification for < 95% Items

When the table above has < 95% items:

1. Design supplementary verification commands (specific, executable)
2. Execute immediately
3. Fill in results
4. Update confidence

Record in subtask.md's "< 95% Supplementary Verification" table.

Boundary for "requires user confirmation" — only scenarios depending on human senses qualify:

• "Selector may have changed" → launch browser and check — NOT "requires user confirmation"
• "API might not work" → curl it — NOT "requires user confirmation"
• "Config might be wrong" → write a script to load and check — NOT "requires user confirmation"
• UI appearance, interaction feel → legitimate "requires user confirmation"

When all items are >= 95%, write "All >= 95%, no supplementary verification needed".

4. Gate 3 Self-Check Checklist

In subtask.md's "Gate 3 Self-Check" section, check each item and provide evidence:

• Verification depth: Test results section has L2+ records
  • Evidence:
• L4 = user path: L4 operation path = actual user usage path
  • Evidence: <state what L4 did, compare with how user would use it>
• Supplementary verification complete: All < 95% items had supplementary verification executed
  • Evidence: <how many items supplemented, or "all >= 95%">
• Instruction file tested: If SKILL.md / config files were changed, they were actually trigger-tested
  • Evidence: <how verified, or "no instruction files changed">
• Coverage complete: Every modified file has a corresponding verification item
  • Evidence: <how many files changed, how many verified>

Can't write evidence = didn't do it = can't check the box = FAIL.

5. Chain Integrity Check

Answer each question (any No → FAIL):

1. Is the chain fully traced? From config/code change → to user-perceivable effect, is there a verification point at every link?
2. Any "should be fine" links? Anything you feel "obviously works" but haven't actually run?
3. Does verification path = user path? Is your verification method consistent with how users actually use it?

6. Write Result and Invoke autoworker:dispatch

PASS (all self-checks pass + all >= 95%):

Edit subtask.md:

1. Append Gate result: PASS at the end of "Progress Log" section
2. Change status: active to status: completed (if status field exists)

Output:

Gate 3 PASS
- Confidence: all >= 95%
- Self-check: 5/5 passed
- Chain: complete
→ Invoking autoworker:dispatch

FAIL loop limit: If already consecutively FAIL 2 times (check "Progress Log" for Gate result: FAIL count), on the 3rd FAIL, do not invoke autoworker:subtask-update. Instead output a complete failure report to the user and let them decide next steps.

FAIL (any self-check fails or has < 95% that can't be self-resolved):

Edit subtask.md, append at end of "Progress Log" section:

Gate result: FAIL

Output:

Gate 3 FAIL
- Failed items: <specifics>
- Needs additional work: <specifics>
→ Invoking autoworker:dispatch

Both cases always invoke autoworker:dispatch. No routing decisions — autoworker:dispatch reads Gate result and decides next step.

7. Chain: Immediately Invoke autoworker:dispatch

After outputting the result, immediately invoke autoworker:dispatch. Do not wait for user instructions, do nothing else.

Important Notes

• gate-check is pure assessment: Only assesses + writes results, does not make routing decisions
• Evidence is a hard constraint: Each self-check item must have traceable evidence — "I think it's fine" doesn't count
• Gate result format is fixed: Must be Gate result: PASS or Gate result: FAIL — autoworker:dispatch reads this exact format
• Don't ask user "should I supplement?": Autonomously executable supplementary verification goes directly through autoworker:dispatch → autoworker:subtask-update loop