simplify

simplify - Quality Gate Stage

Invariants

• Review only the task scope and changed files.
• Do not add new product scope.
• Block major deviations before testing.
• Write durable findings to the task document.
• If the task doc has an Implementation Notes section but TASKS.md still shows the row in Planned or In Progress, reconcile the row to Testing before continuing — implement ran but missed its tracker update. If Implementation Notes is absent, do not reconcile; implement genuinely did not run and the user should be told.

Runtime adapters may expose this stage as a slash command, menu action, or natural-language skill invocation. The portable stage name is simplify.

Workflow

1. Read AGENTS.md.
2. Resolve the task ID and read docs/task/{ID}-{task-name}.md.
3. Identify changed files from Implementation Notes and git diff --name-only.
4. Read changed files only.
5. Check coding standards and maintainability.
6. Compare implementation against requirements, file changes, out-of-scope boundaries, and acceptance criteria.
7. Classify deviations.
8. Append Quality Gate Notes to the task document.
9. Return PASS or FAIL.

No Task Document

For a small change the user asked for directly, with no docs/task/ doc (a quick fix or polish):

• Review the diff (git diff against the base branch) against the user's request instead of a task doc.
• Apply the same standards checklist and deviation levels. "Scope" is what the user asked for.
• Record the result (PASS/FAIL, findings, deviations) in the pull request body or the commit message, not in a new task doc.
• Don't create TASKS.md rows for it unless the project asks for that.

Standards Checklist

Apply where relevant:

• no unused code, dead code, or commented-out implementation
• no broad any or untyped escape hatches when the project has typed alternatives
• no deep nesting where guard clauses would be clearer
• functions and files have clear responsibility
• names describe behavior accurately
• repeated logic is extracted when repetition creates maintenance risk
• errors are handled intentionally
• no secrets, credentials, or debug logging in production paths
• tests that assert on old behaviour or wording are updated deliberately, with a comment saying why, never just deleted
• new or changed tests check behaviour or output where they can; a test that only asserts source text or structure is flagged as weak evidence
• every acceptance criterion in the task doc has a check that could fail; flag any that don't
• project conventions from AGENTS.md, LEARNINGS.md, and the task doc are followed

Deviation Classification

Level	Meaning	Outcome
Minor	Small implementation difference that still satisfies scope.	Document and proceed.
Medium	Meaningful difference that should be visible to the user.	Document and proceed only if risk is acceptable.
Major	Violates requirements, expands scope, or changes architecture without approval.	FAIL and stop.

Output In Task Document

## Quality Gate Notes

### Result
PASS | FAIL

### Standards Review
- {Finding or "No blocking issues"}

### Deviations
- {Deviation level and rationale}

### Required Fixes
- {Only if FAIL}

Handoff

PASS:

Quality gate passed for task {ID}
Next stage: test {ID}

FAIL:

Quality gate failed for task {ID}
Return to implementation with the required fixes listed in the task document.