# Pathrule Pattern: AI-Generated Code Verification (1.0.0) # ::pathrule:package:ai-code-verification ### [RULE] Require evidence for every behavior and API claim (path: /src) Generated code can confidently import a removed symbol, assume a default, or describe a test result that was never produced. Plausibility is not repository evidence. - Resolve APIs, configuration keys, defaults, and version-sensitive behavior from the installed dependency, source, or current official documentation. - Run the narrowest relevant build, type, static, unit, integration, and runtime checks and preserve their exact outcome. - Do not claim an endpoint, UI, migration, or recovery flow works unless it was exercised or clearly label the unverified boundary. - Remove or rewrite uncertain behavior that cannot be verified instead of adding comments that repeat the guess. See /tests for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Keep generated changes inside the authorized scope (path: /src) A coding agent can broaden a small task into cleanup or architecture change that was never requested. Even individually reasonable edits increase review cost and hide regressions. - Map each changed file and behavior to the user request or a necessary implementation step and revert no protected user or team work. - Search for existing helpers, services, schemas, components, and conventions before adding a parallel implementation. - Treat permission, authorization, validation, migration, secret, external-effect, and destructive-command changes as high-risk scope that needs direct evidence. - Review generated dependency, lockfile, snapshot, schema, and build output separately from authored source and regenerate only through the repository toolchain. See /docs/ai-review for the adjacent decision or procedure that completes this constraint. --- ### [MEMORY] AI provenance changes review strategy, not accountability (path: /docs/ai-review) AI code does not need a weaker or purely stylistic review. It needs extra attention to repository-wide assumptions the generator may not have seen, but the acceptance bar remains the system's ordinary correctness and safety contract. - Review at behavior and ownership boundaries before line polish: input, authorization, state, effects, failure, concurrency, privacy, and recovery. - Ask which repository rule, memory, existing implementation, source, or runtime evidence supports each non-obvious decision. - Use model or tool metadata for audit and improvement where policy permits, but do not treat it as a substitute for code ownership. - Assign a human or team owner who can operate, rollback, and maintain the generated change after the conversation that produced it is gone. See /src for the rule or workflow that puts this decision into practice. --- ### [MEMORY] A verification report separates passed, failed, and untested (path: /docs/ai-review) A report that says tests pass without naming the suite, or says production-ready after only compilation, prevents reviewers from judging evidence strength. - List each executed check with target, environment, exit outcome, and relevant artifact or observation. - List failures and how they were repaired, because repeated mistakes reveal risk areas that deserve review. - Name untested platforms, browsers, integrations, migrations, loads, credentials, and destructive or external flows explicitly. - Keep inference separate from observation and state what evidence would be needed to close each remaining uncertainty. See /tests for the rule or workflow that puts this decision into practice. --- ### [SKILL] review-ai-generated-change (path: /) --- name: review-ai-generated-change description: Review code produced wholly or partly by a coding agent before merge. --- # Review Ai Generated Change Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result. 1. Restate requested behavior and map every changed file, dependency, generated artifact, and external effect to that scope. 2. Compare against repository instructions, nearby implementations, schemas, ownership boundaries, and installed dependency APIs before accepting new abstractions. 3. Trace untrusted input through validation, authentication, authorization, persistence, output, logging, and cleanup, including error and cancellation paths. 4. Run focused and broad checks proportional to risk and inspect whether tests would fail on the pre-change defect instead of merely covering the new code. 5. Verify runtime behavior and rollback for the complete user flow, then write a report that separates evidence, inference, and untested boundaries. ## Exit criteria The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks. --- ### [SKILL] verify-generated-change-runtime (path: /) --- name: verify-generated-change-runtime description: Verify an AI-generated feature or fix in the real application environment. --- # Verify Generated Change Runtime Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result. 1. Start from the user or system entry point and capture the baseline failure or expected pre-change limitation. 2. Exercise valid, invalid, unauthorized, duplicate, concurrent, timeout, cancellation, dependency-failure, and recovery paths with representative data. 3. Inspect API, database, queue, file, log, metric, and external-side-effect evidence so the visible result is tied to authoritative state. 4. Restart, reload, navigate, retry, or redeploy according to the feature lifecycle and confirm state remains consistent. 5. Execute rollback or disablement and verify migrated data and external effects remain supportable before declaring the change complete. ## Exit criteria The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.