Update to Argovance Skill OS

{
  "description": "Verify a completed or staged implementation against its approved specification, real functionality, visual and perceptual targets, accessibility, performance, responsive behavior, supported environments, regression boundaries, release evidence, and rollback readiness. Use as a strict post-implementation release gate. Do not use for pre-development document auditing, implementation, defect repair, or redesign.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 299
    }
  ],
  "name": "verify-production-implementation",
  "skill_md_contents": "---\nname: verify-production-implementation\ndescription: Verify a completed or staged implementation against its approved specification, real functionality, visual and perceptual targets, accessibility, performance, responsive behavior, supported environments, regression boundaries, release evidence, and rollback readiness. Use as a strict post-implementation release gate. Do not use for pre-development document auditing, implementation, defect repair, or redesign.\n---\n\n# Verify Production Implementation\n\nAct as an independent post-implementation gatekeeper. Report evidence and verdicts; do not repair the implementation or rewrite its specification.\n\n## Preserve independence\n\n- Identify the implementation owner, decision owners, and proposed reviewers.\n- Do not allow the same role to independently approve its own critical implementation or Class-2 decision.\n- Inspect only accessible evidence and mark unavailable areas `NOT VERIFIABLE`.\n- Do not deploy, publish, merge, release, alter code, update snapshots, waive failures, or change external state.\n- Route pre-implementation document readiness to `$project-specification-auditor`, normal between-gate ratification to `$verify-implementation-checkpoint`, and repairs to the relevant implementation or defect skill. This skill remains the final release gate and does not absorb routine checkpoint verification.\n\n## Establish the verification contract\n\n1. Inventory approved specifications, source manifest and precedence, task execution contracts, Class-2 decisions, changed files, tests, environments, checkpoints, known deviations, and rollback.\n2. Confirm the real build or staged environment corresponds to the claimed revision and configuration.\n3. Trace each requirement and material observable to implementation evidence and acceptance.\n4. Use the shared [risk-adaptive assurance model](../../shared/expert-system/risk-adaptive-assurance-model.md), [specialist review model](../../shared/expert-system/specialist-review-model.md), [observable ownership](../../shared/expert-system/observable-ownership.md), and [perceptual quality gates](../../shared/expert-system/perceptual-quality-gates.md).\n5. Identify the direct acceptance oracle for each material claim, confirm the measurement-relevant acceptance environment, and reject circular proof where the candidate controls both expected and observed truth.\n6. Apply the shared [Product Quality Principles](../../shared/expert-system/product-quality-principles.md) only to relevant accepted requirements and observable release behavior; the principles do not add features or replace specialist evidence.\n\n## Verification dimensions\n\nCheck as applicable:\n\n- specification fidelity and explicitly approved deviations;\n- real functional behavior, permissions, state transitions, user agency, cancellation/undo where required, destructive-action boundaries, failures, recovery, and data effects;\n- architecture and interface compatibility;\n- visual fidelity, composition, hierarchy, typography, materials, lighting, motion, interaction, and brand coherence;\n- responsive behavior, browser, device, input context, theme, scope-relevant localization, and reduced motion;\n- accessibility semantics, keyboard behavior, focus, contrast, assistive output, and target standard;\n- performance, capacity, runtime resources, loading, and interaction budgets;\n- security-relevant controls, privacy, secrets, logging, and abuse cases;\n- migrations, deployment, monitoring, smoke tests, rollback, and operational readiness;\n- interface-language clarity for consequential actions, states, errors and recovery, routing depth review to `$review-interface-language-and-naming` where required;\n- final craft/detail across applicable technical and perceptual observables;\n- regressions against protected behavior and last approved checkpoint.\n\nInspect the actual output. Do not award pass from a process log, test report, screenshot, or numeric metric that does not prove the target. Correct compliance with a defective specification is not success.\n\n## Gate logic\n\nRate each applicable dimension `PASS`, `PASS WITH RISKS`, `FAIL`, or `NOT VERIFIABLE`.\n\n- Any material technical, functional, accessibility, security, data, release, regression, or perceptual failure makes the overall result `FAIL`.\n- Technical pass plus perceptual fail is `FAIL`.\n- Perceptual pass plus technical fail is `FAIL`.\n- A required dimension that is not verifiable blocks release.\n- Non-blocking risks require owner, impact, evidence, and acceptance authority.\n\n## Output\n\nReturn:\n\n1. overall verdict: `RELEASE READY`, `READY WITH ACCEPTED RISKS`, or `NOT RELEASE READY`;\n2. inspected revision, environment, sources, and evidence;\n3. requirement and observable traceability;\n4. dimension results;\n5. failures, regressions, deviations, and unverified areas;\n6. independent reviewer record;\n7. rollback and operational readiness;\n8. exact conditions for re-verification.\n\nNever repair findings inside this skill.\n\nDedicated accessibility depth belongs to `$audit-accessibility-and-inclusive-design`; behavioral AI quality belongs to `$evaluate-ai-systems`. This final gate consumes their evidence when required instead of duplicating their specialist audits.\n"
}