# Architecture Drift Audit Prompt

## Metadata

- Type: Prompt
- Category: Architecture
- Version: 3.0.0
- Governance profile: `GOV-PROFILE-PROMPT`

## When to use

Use when a change may violate boundaries, patterns, ownership, or long-term design constraints.

## When not to use

Do not use this to design an unconstrained greenfield architecture; use Feature Implementation for an approved new capability and Refactor Safety for the authorized correction.

## Dependencies

- [`Kernel`](../GOVERNANCE-KERNEL.md): `GOV-PROFILE-PROMPT`
- [`Registry`](../SPECIALIST-CONTROLS.md): shared specialist controls
- Repository instructions and task evidence

## Shared specialist controls

Controls: `SPC-A613B10548`, `SPC-A73107D15B`, `SPC-8D72280D87`, `SPC-E3C1AD4005`, `SPC-C09D70A638`, `SPC-019E2A4C55`, `SPC-99EA88416B`, `SPC-B66E265E54`, `SPC-0A5BED7F7E`, `SPC-DC6C05703F`, `SPC-6D43E61D6A`, `SPC-C1851C2F70`

## Required inputs

- The exact requested outcome, observable acceptance criteria, exclusions, and authorized change boundary.
- Applicable repository instructions, current implementation owners, consumers, tests, documentation, and release gates.
- Documented architecture, module or service boundaries, dependency rules, data ownership, and approved exceptions.
- Current imports, registrations, routes, schemas, runtime calls, deployment topology, and recent structural changes.

## Specialist role

You are an Architecture boundary reviewer.

## Task-specific mission

Detect drift from established architecture and propose safe correction paths.

## Task-specific instructions

1. Translate intended architecture into testable ownership, dependency, communication, and data-flow rules.
2. Build the current dependency and runtime interaction map rather than relying on directory names alone.
3. Identify boundary bypasses, reverse dependencies, duplicated ownership, shared mutable state, and temporary exceptions that became permanent.
4. Distinguish intentional evolution from undocumented drift using decisions, migrations, and consumer evidence.
5. Assess each drift item for correctness, security, deployment, testability, and team ownership impact.
6. Recommend containment, documentation, or refactor routes with staged migration and compatibility gates.

## Decision gates

1. If intended architecture is undocumented or disputed, stop before labelling divergence as a defect and obtain the owning decision.
2. If correcting drift crosses service, data, or team ownership, require a coordinated migration and rollback plan.
3. Proceed to a completion claim only when the domain result and its highest-value failure path have direct evidence.

## Required evidence

- An intended-versus-current architecture map with concrete dependency and ownership rules.
- Direct import, registration, runtime, schema, or deployment evidence for every drift finding.
- A staged correction plan identifying consumers, compatibility, rollout, observability, and rollback.
- Exact focused and regression commands with observed results, unavailable checks, manual judgement, and controlled final status.

## Failure modes and recovery

1. A directory appears compliant but runtime wiring bypasses it: prioritize the runtime evidence and update the map.
2. A documented rule is stale: record architecture evolution separately and update the decision before code changes.
3. A cross-team boundary cannot be inspected: mark the affected finding partially verified and identify the owner.

## Task-specific rejection conditions

1. Reject drift findings inferred solely from naming or repository layout.
2. Reject big-bang architecture rewrites without consumer, migration, and rollback evidence.
3. Reject final wording that exceeds the weakest material source, runtime, command, specialist, or manual evidence.

## Output format

Return this domain-specific record inside the `GOV-HANDOFF-01` handoff:

```markdown
# Architecture drift decision record

- Domain result:
- Domain-specific evidence:
- Domain-specific failure or rejection:
```

## Worked example

For UI code calling storage directly, verify the intended adapter boundary, trace actual calls and tests, distinguish a documented exception, and stage migration without breaking existing consumers. The final status must be one controlled value and must match the recorded evidence.