ci/opencode/ci/workflows/verify.md

description

description
Verify CI project deliverables against requirements — structural, behavioral, security, and quality checks

CI Verify

Run the CI verification pipeline against the current or specified phase. Four layers: structural, behavioral, security, quality.

Usage: ci-verify [phase_number]

If no phase specified, verifies the current phase.

Step 0: Confirm Active Project

Check ci listProjects() or read .ci/config.json to determine if multi-project mode is active.

If .ci/config.json has projects[] with length > 0:

• Confirm active_project is correct for this verification
• If not, set it with ci setActiveProject(<slug>)
• Scope verification to the active project
• All commit messages must include project: <slug> in ---ci--- block

If single-project mode: proceed with existing conventions.

Phase Boundary Checkpoint: Between phases, all state is committed to git, context is reset, and the next phase begins with fresh git log context. Verify that the current verification aligns with the reconstructed state.

Step 1: Load Git Context

git log --max-count=30
git branch -a

Determine the phase to verify from git context or argument.

Step 2: Structural Verification (Layer 1)

Check:

1. All files referenced in plans exist on disk
2. All imports resolve (no dangling references)
3. No stub implementations or TODO placeholders
4. All declared exports actually exist

Run: npm run typecheck or equivalent Run: npm run build or equivalent

Step 3: Behavioral Verification (Layer 2)

Check:

1. All tests pass: npm test
2. Must-have criteria from plan frontmatter are met
3. Requirement coverage: each REQ-ID for this phase is covered

For unverifiable items: auto-generate test scripts.

Step 4: Security Verification (Layer 3)

STRIDE analysis:

• Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege

Auto-disposition: low=accept, medium=mitigate, high=escalate.

Step 5: Quality Verification (Layer 4)

Multi-persona code review:

• Correctness: logic errors, edge cases
• Testing: coverage gaps, flaky tests
• Security: input validation, injection vectors
• Performance: unnecessary allocations, O(n^2)
• Maintainability: naming, structure, coupling
• Adversarial: attack surface, abuse cases

P0 fixes are auto-applied. P1+ are flagged for post-hoc review.

Step 6: Commit Results

verify(P##): [passed|gaps_found]

---ci---
phase: [N]
milestone: [vX.X]
status: verify
requirements:
  covered: [REQ-01, REQ-02]
  partial: [REQ-03]
lessons:
  - [lesson from verification]
---/ci---

Step 7: Return Result

Report verification score, any gaps found, and next steps.