Aif Verify

Verify — Post-Implementation Quality Check

Verify that the completed implementation matches the plan, nothing was missed, and the code is production-ready.

This skill is optional — invoked after /aif-implement finishes all tasks, or manually at any time.

Step 0: Load Context

0.0 Load config.yaml

FIRST: Read .ai-factory/config.yaml if it exists to resolve:

• Paths: paths.description, paths.architecture, paths.rules_file, paths.roadmap, paths.research, paths.plan, paths.plans, paths.fix_plan, paths.specs, paths.rules, and paths.archive; derive research_bundles_dir = <parent directory of paths.research>/research/
• verify_mode: default verification strictness (strict | normal | lenient)
• Git: git.enabled, git.base_branch, git.create_branches
• Rules hierarchy: the resolved RULES.md path + rules.base + named rules.<area> entries
• Language: language.ui for prompts, user-visible explanations, verification reports, context-gate summaries, issue remediation prompts, and next-step guidance
• Workflow: workflow.plan_id_format (default: slug) — used by branch-based plan discovery in Step 0.2. Active values: slug and sequential. Discovery treats root *.md files as full plans except the resolved fast/fix paths, and direct child */index.md files as ultra entrypoints only when they contain exactly one <!-- aif:plan-mode:ultra -->. When sequential, search both numbered shapes and choose the highest prefix. timestamp and uuid are reserved values and currently behave like slug. Treat any unknown value as slug.

verify_mode priority:

1. --strict CLI flag → always use strict
2. config.yaml workflow.verify_mode → use configured value
3. Default → normal

If config.yaml doesn't exist, use defaults:

• Paths: .ai-factory/ for all artifacts
• research: .ai-factory/RESEARCH.md
• verify_mode: normal
• Rules: RULES.md only
• ui_language: en
• workflow.plan_id_format: slug

Resolved language value:

• ui_language = language.ui || "en"

All AskUserQuestion prompts, user-visible explanations, verification reports, context-gate summaries, issue remediation prompts, and next-step guidance MUST be written in ui_language.

Preserve machine-readable aif-gate-result JSON schema fields and enum values (pass, warn, fail) unchanged. Preserve WARN/ERROR gate labels, commands, paths, config keys, code identifiers, package names, API names, and raw command output unchanged.

0.1 Load Ownership and Gate Contract

• Read references/CONTEXT-GATES-AND-OWNERSHIP.md first.
• Read references/GATE-RESULT-CONTRACT.md for the machine-readable quality gate summary.
• Treat it as the canonical source for:
  • command-to-artifact ownership,
  • read-only behavior for aif-commit/aif-review/aif-verify,
  • normal vs strict context-gate thresholds.
• If this contract conflicts with older examples in this file, follow the contract.

0.2 Find Plan Artifact

Same logic as /aif-implement — produce the canonical branch stem before any plans-dir glob so producer and consumers agree by construction.

1. Check current git branch:
   git branch --show-current
2. Convert branch to filename stem (git mode only):
   branch_stem = current branch with every "/" replaced by "-"
   Example: feature/user-auth → feature-user-auth
3. Resolve the plan artifact using <branch_stem>:
   → When `workflow.plan_id_format = sequential`, glob both
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>.md
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>/index.md
     Read every directory candidate and retain it only when `index.md` contains
     exactly one <!-- aif:plan-mode:ultra -->. Choose the highest prefix across
     valid artifacts and warn when multiple valid candidates exist; prefer ultra
     if both shapes share the highest prefix.
   → Otherwise/fallback check the ultra entrypoint and full file:
       <configured plans dir>/<branch_stem>/index.md
       <configured plans dir>/<branch_stem>.md
     Read the directory entrypoint before selection and ignore it unless it
     contains exactly one <!-- aif:plan-mode:ultra -->. If both valid shapes
     exist, warn and prefer ultra.
4. If the branch-based plan is missing or git mode is off:
   → Count root `*.md` full plans and declared-ultra direct child `*/index.md`
     entrypoints as artifacts; exclude resolved fast/fix paths and do not count
     phase files
   → If exactly one exists, use it
   → If multiple exist, ask the user to choose or use `@<path>` via `/aif-implement`
5. No named full/ultra plan → Check the resolved fast plan path
6. No regular plan and no resolved fast plan → fall back to standalone verification choices

Note: Plan discovery scans paths.plans/ only. Plans archived to paths.archive/plans/ by /aif-archive are excluded from discovery. If a plan is found only in the archive, emit WARN [aif-verify] plan <name> is archived; verifying archived plan.

If no plan artifact is found:

AskUserQuestion: No plan artifact found. What should I verify?

Options:
1. Verify last commit — Check the most recent commit for completeness
2. Verify branch diff — Compare current branch against the configured base branch
3. Cancel

0.3 Read Plan & Tasks

• Read the selected plan entrypoint to understand what was supposed to be implemented
• An automatically discovered directory entrypoint is a plan only when it contains <!-- aif:plan-mode:ultra -->; ignore unrelated */index.md files.
• For ultra, validate all Phase Index links and read every linked phase file before verification. Verify implementation against the detailed per-task interfaces, edge cases, logging, acceptance criteria, and commands—not only the short checkbox text in index.md. A missing/broken/escaping phase link is a blocking plan-integrity failure because the committed specification is incomplete.
• Cross-check every Task N in index.md against exactly one matching ## Task N section in its linked phase file. Unmapped tasks, duplicate task sections, and unlinked phase-*.md files are blocking plan-integrity failures.
• TaskList → get all tasks and their statuses
• Read .ai-factory/DESCRIPTION.md (use path from config) for project context (tech stack, conventions)
• Read .ai-factory/ARCHITECTURE.md (use path from config) for dependency and boundary rules (if present)
• Read rules hierarchy (use paths from config):
  1. RULES.md — axioms (universal project rules)
  2. rules/base.md — project-specific base conventions
  3. rules.<area> — area-specific rule entries resolved from config (for example rules.api, rules.frontend)
• Read .ai-factory/ROADMAP.md (use path from config) for milestone alignment checks (if present)
• If the plan entrypoint contains ## Original Request, treat it as useful original scope context. Use it to understand the user's starting intent, while the task list, committed ## Research Context, and ultra phase specifications remain the executable verification inputs.
• If the plan entrypoint contains ## Research Context, treat its embedded copy as the committed requirements snapshot. Parse the first Source: / Reference: line with canonical ^(?:Source|Reference):\s+\x60([^\x60]+)\x60\s+\( syntax; for older bare-path lines, fall back to ^(?:Source|Reference):\s+(.+?)\s+\(. Fall back to configured paths.research only when neither form identifies a usable path.
• If the parsed source is inside research_bundles_dir, require its sibling INDEX.md to contain <!-- aif:research-mode:ultra --> exactly once and link that RESEARCH.md from ## Artifact Index; otherwise emit WARN [research-drift]. Sibling C4/ADR/dependency files remain rationale only.
• When SHA256: is present, extract the current source text strictly between <!-- aif:active-summary:start --> and <!-- aif:active-summary:end -->, remove HTML comment blocks, preserve line order and leading whitespace, trim trailing spaces from every line, use LF endings, and end with one newline. Hash through stdin with shasum -a 256 or sha256sum; the digest is authoritative. Use Updated: only as a legacy fallback when SHA256: is absent. A missing/invalid source or revision mismatch emits WARN [research-drift]; verify against the embedded Research Context and do not expand scope unless the user explicitly requests a rebase/refinement. Skipping this drift check is a verification bug.
• Compatibility wording for the same rule: emit WARN [research-drift] and verify against the plan's embedded Research Context.

Read .ai-factory/skill-context/aif-verify/SKILL.md — MANDATORY if the file exists.

This file contains project-specific rules accumulated by /aif-evolve from patches, codebase conventions, and tech-stack analysis. These rules are tailored to the current project.

How to apply skill-context rules:

• Treat them as project-level overrides for this skill's general instructions
• When a skill-context rule conflicts with a general rule written in this SKILL.md, the skill-context rule wins (more specific context takes priority — same principle as nested CLAUDE.md files)
• When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
• Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults — they exist because the project's experience proved the default insufficient
• CRITICAL: skill-context rules apply to ALL outputs of this skill — including the Verification Report template. If a skill-context rule says "verification MUST check X" or "report MUST include section Y" — you MUST augment the report accordingly. Generating a verification that ignores skill-context rules is a bug.

Enforcement: After generating any output artifact, verify it against all skill-context rules. If any rule is violated — fix the output before presenting it to the user.

0.3 Gather Changed Files

# All files changed during this feature/plan
git diff --name-only <configured-base-branch>...HEAD
# Or if on the base branch / in no-git mode, check recent commits
git diff --name-only HEAD~$(number_of_tasks)..HEAD

If git.enabled = false, skip branch diffing entirely and gather changed files from:

• the working tree (if uncommitted changes exist), or
• the recent commit window that corresponds to the implemented tasks.

Store as CHANGED_FILES.

Step 1: Task Completion Audit

Go through every task in the plan and verify it was actually implemented.

For each task:

1.1 Read Task Description

TaskGet(taskId) → Get full description, requirements, acceptance criteria

1.2 Verify Implementation Exists

For each requirement in the task description:

• Use Glob and Grep to find the code that implements it
• Read the relevant files to confirm the implementation is complete
• Check that the implementation matches what was described, not just that "something was written"

1.3 Build Checklist

For each task, produce a verification result:

✅ Task #1: Create user model — COMPLETE
   - User model created at src/models/user.ts
   - All fields present (id, email, name, createdAt, updatedAt)
   - Validation decorators added

⚠️ Task #3: Add password reset endpoint — PARTIAL
   - Endpoint created at src/api/auth/reset.ts
   - MISSING: Email sending logic (task mentioned SendGrid integration)
   - MISSING: Token expiration check

❌ Task #5: Add rate limiting — NOT FOUND
   - No rate limiting middleware detected
   - No rate-limit related packages in dependencies

Statuses:

• ✅ COMPLETE — all requirements verified in code
• ⚠️ PARTIAL — some requirements implemented, some missing
• ❌ NOT FOUND — implementation not detected
• ⏭️ SKIPPED — task was intentionally skipped by user during implement

Step 2: Code Quality Verification

2.1 Build & Compile Check

Detect the build system and verify the project compiles:

If build fails → report errors with file:line references.

2.2 Test Check

If the project has tests and they were part of the plan:

If tests fail → report which tests failed and whether they relate to the implemented tasks.

If no tests exist or testing was explicitly skipped in the plan → note it but don't fail.

2.3 Lint Check

If linters are configured:

Only lint the changed files to keep output focused.

2.4 Import & Dependency Check

• Verify no unused imports were left behind
• Check that new dependencies mentioned in tasks were actually added (package.json, go.mod, requirements.txt, composer.json)
• Check for missing dependencies (imports that reference packages not in dependency files)

Step 3: Consistency Checks

3.1 Plan vs Code Drift

Check for discrepancies between what the plan says and what was built:

• Naming: Do variable/function/endpoint names match what the plan specified?
• File locations: Are files where the plan said they should be?
• API contracts: Do endpoint paths, request/response shapes match the plan?