pair-capability-verify-adoption

name	pair-capability-verify-adoption
description	Detects conformity/non-conformity of already-written code and configuration against the project's adopted decisions (architecture, tech-stack, infrastructure, etc.), for a given scope — a compliance audit, not a new-choice evaluation (that's /pair-capability-assess-stack and siblings). Detection-only; resolution is the caller's. Composed by /pair-process-review and /pair-process-implement; invoke directly to audit a scope on demand.
version	0.4.1
author	Foomakers

/pair-capability-verify-adoption — Adoption Compliance Checker

Check code, configuration, or a PR against the project's adoption files. Detection-only — returns a conformity/non-conformity list per area. Does NOT resolve issues; resolution is the caller's responsibility.

Arguments

Argument	Required	Description
$scope	Yes	Area to check: tech-stack, architecture, security, coding-standards, infrastructure, all. Determines which adoption files are read.

Scope-to-Adoption Mapping

Scope	Adoption File(s)
tech-stack	adoption/tech/tech-stack.md
architecture	adoption/tech/architecture.md + adoption/tech/adr/
security	Security-related sections in adoption files + security guidelines
coding-standards	Code design adoption + code-design guidelines
infrastructure	adoption/tech/infrastructure.md
all	All of the above

Algorithm

For each area in scope, follow the check → skip → act → verify pattern.

Step 1: Resolve Scope

1. Check: Is $scope provided?
2. Act: If $scope = all, expand to all 5 areas: tech-stack, architecture, security, coding-standards, infrastructure.
3. Act: If single scope, use only that area.
4. Verify: Area list determined.

Step 2: Check Tech Stack Compliance

Skip if tech-stack not in resolved scope.

1. Check: Does adoption/tech/tech-stack.md exist and contain project-specific content?
2. Skip: If adoption file missing or template-only → report tech-stack: NOT CONFIGURED and move to next area.
3. Act: Read the adoption file. Extract adopted technologies with versions. Scan the codebase or PR for:
   • Dependencies not listed in tech-stack.md (unlisted imports, package.json entries)
   • Version mismatches (code uses a different version than adopted)
   • Deprecated or removed technologies still in use
4. Verify: Report per finding:
   • CONFORMANT: All dependencies match adoption.
   • NON-CONFORMANT: List each violation with file, dependency, and reason.

Step 3: Check Architecture Compliance

Skip if architecture not in resolved scope.

1. Check: Does adoption/tech/architecture.md exist with project-specific content?
2. Skip: If missing → report architecture: NOT CONFIGURED and move to next area.
3. Act: Read architecture adoption and existing ADRs in adoption/tech/adr/. Check code for:
   • Pattern violations (e.g., direct DB access bypassing service layer)
   • Layer boundary crossings not permitted by the architecture
   • Architectural changes without a corresponding ADR
   • ADR decisions not reflected in implementation
4. Verify: Report CONFORMANT or NON-CONFORMANT with findings.

Step 4: Check Security Compliance

Skip if security not in resolved scope.

1. Check: Do security-related adoption files or security guidelines exist?
2. Skip: If no security guidelines found → report security: NOT CONFIGURED and move to next area.
3. Act: Check code for:
   • Hardcoded secrets or credentials
   • Input validation gaps at system boundaries
   • Injection vulnerabilities (SQL, command, XSS)
   • Improper data handling or logging of sensitive data
   • Missing authentication/authorization checks
4. Verify: Report CONFORMANT or NON-CONFORMANT with findings.

Step 5: Check Coding Standards Compliance

Skip if coding-standards not in resolved scope.

1. Check: Do code-design guidelines or coding standards adoption files exist?
2. Skip: If missing → report coding-standards: NOT CONFIGURED and move to next area.
3. Act: Check code for:
   • Naming convention violations
   • File/module organization deviations from adopted patterns
   • Missing or improper error handling patterns
   • Test structure violations (1:1 mapping, behavior-based tests)
4. Verify: Report CONFORMANT or NON-CONFORMANT with findings.

Step 6: Check Infrastructure Compliance

Skip if infrastructure not in resolved scope.

1. Check: Does adoption/tech/infrastructure.md exist with project-specific content?
2. Skip: If missing → report infrastructure: NOT CONFIGURED and move to next area.
3. Act: Read infrastructure adoption. Check for:
   • CI/CD configuration deviations from adopted pipeline
   • Deployment patterns not matching adopted infrastructure
   • Environment configuration inconsistencies
4. Verify: Report CONFORMANT or NON-CONFORMANT with findings.

Output Format

ADOPTION COMPLIANCE REPORT:
├── Scope:           [$scope — expanded areas]
├── Tech Stack:      [CONFORMANT | NON-CONFORMANT — N findings | NOT CONFIGURED]
├── Architecture:    [CONFORMANT | NON-CONFORMANT — N findings | NOT CONFIGURED]
├── Security:        [CONFORMANT | NON-CONFORMANT — N findings | NOT CONFIGURED]
├── Coding Standards:[CONFORMANT | NON-CONFORMANT — N findings | NOT CONFIGURED]
└── Infrastructure:  [CONFORMANT | NON-CONFORMANT — N findings | NOT CONFIGURED]

FINDINGS (if any):
1. [area] — [description] ([file:line])
   Resolution: [/assess-stack | /record-decision | developer action]
2. ...

RESULT: [ALL CONFORMANT | N non-conformities across N areas]

Resolution Routing

This skill does NOT resolve non-conformities. It routes them to the appropriate resolver:

Area	Resolver	Rationale
Tech Stack	/pair-capability-assess-stack	Stack changes go through tech assessment
Architecture	/pair-capability-record-decision	Architectural gaps need an ADR
Security	Developer action	Security fixes are context-specific
Coding Standards	Developer action	Code style fixes are manual
Infrastructure	Developer action	Infra changes need manual review

Composition Interface

When composed by /pair-process-review:

• Input: /pair-process-review invokes /pair-capability-verify-adoption with $scope=all during the adoption compliance phase.
• Output: Returns the compliance report. /pair-process-review incorporates findings into review output.
  • NON-CONFORMANT areas contribute to CHANGES-REQUESTED verdict.
  • NOT CONFIGURED areas are noted but do not block.

When composed by /pair-process-implement:

• Input: /pair-process-implement may invoke /pair-capability-verify-adoption with a targeted $scope (e.g., tech-stack) before commit.
• Output: Returns the compliance report. /pair-process-implement resolves non-conformities via /pair-capability-assess-stack or /pair-capability-record-decision.
  • Unresolved non-conformities do not HALT — /pair-process-implement warns and continues.

When invoked independently:

• Full interactive flow. Developer receives the compliance report and decides resolution.
• This skill only reads and reports — it does not modify files.

Graceful Degradation

See graceful degradation (adoption file missing → report as NOT CONFIGURED, don't fail; guideline missing → check only what's derivable) for the standard scenarios. Additional cases:

• If $scope=all and no adoption files exist at all, report: "No adoption files found — run /pair-process-bootstrap to establish project standards."
• If the codebase is empty or no code changes to check, report all areas as CONFORMANT (nothing to violate).

Notes

• This skill is read-only — it inspects code and adoption files but never modifies anything.
• Detection-only contract: the skill identifies non-conformities but never resolves them. Resolution is always delegated to the caller or the appropriate skill.
• Idempotent — see idempotency convention. This skill's check: conformant code is confirmed immediately; non-conformant code returns the same findings until fixed.
• Scope is mandatory to prevent accidental full scans when only a targeted check is needed. Use all explicitly for comprehensive checks.
• Contextual checking: when invoked on a PR, only changes in the PR are checked, not the entire codebase. When invoked independently, the scope of code analysis is determined by the area.