engineering-intelligence 1.3.0 → 1.5.0

package/templates/canonical/skills/aidlc-lifecycle-engine/SKILL.md

@@ -18,6 +18,7 @@ Use `.engineering-intelligence/aidlc/` as the canonical AI-DLC root:
 | `.engineering-intelligence/aidlc/audit.md` | Append-only chronological log of decisions, user answers, tool checks, and transitions |
 | `.engineering-intelligence/aidlc/open-questions.md` | Unresolved ambiguities and owner/status |
 | `.engineering-intelligence/aidlc/execution-plan.md` | Adaptive stage plan with mandatory/conditional/skipped stages |
+| `.engineering-intelligence/aidlc/checkpoints.md` | Resume checkpoints after major workflow steps |
 | `.engineering-intelligence/aidlc/discovery/vision.md` | Business objectives, personas, value, success metrics |
 | `.engineering-intelligence/aidlc/discovery/technical-environment.md` | Runtime, deployment, integrations, data stores, auth, constraints |
 | `.engineering-intelligence/aidlc/agile/product-backlog.md` | Epics, stories, priorities, dependencies, and status |
@@ -78,6 +79,16 @@ For brownfield systems, run reverse engineering and write:
 
 Then compile validated requirements, backlog updates, acceptance criteria, sprint plan, and an adaptive `execution-plan.md`.
 
+`execution-plan.md` must include a formal unit dependency graph:
+
+```markdown
+## Units Dependency Graph
+| Unit | Depends On | Can Run In Parallel | Files Owned | Conflict Risk |
+|---|---|---|---|---|
+```
+
+Units with no declared dependencies and no overlapping owned files may run in parallel. Conflicts discovered during parallel or sequential execution must be logged in `cross-unit-discoveries.md`.
+
 ### 2. Construction
 
 Execute per unit of work. Each unit may include:
@@ -115,6 +126,32 @@ Each stage must end with binary evidence:
 - Required tests, type checks, linters, scans, or build commands ran, failed, or were explicitly unavailable
 - Human approval is recorded before irreversible actions
 - Breadcrumb is updated in `aidlc-state.md`
+- Checkpoint is written after impact analysis, implementation, type/API/migration safety gates, validation, synchronization, and change record
+
+## Checkpoint And Resume
+
+Write `.engineering-intelligence/aidlc/checkpoints.md` and update `aidlc-state.md` after each major step:
+
+| Checkpoint | Meaning | Resume Action |
+|---|---|---|
+| `impact-analysis-complete` | Impact report exists | Resume at implementation planning |
+| `implementation-complete` | Code edits are done | Resume at validation |
+| `safety-gates-complete` | Type/API/migration gates passed or blocked | Resume at testing/backpressure |
+| `tests-passing` | Required validation passed | Resume at sync |
+| `sync-complete` | Intelligence artifacts updated | Resume at change record |
+| `change-record-complete` | CHG record exists | Resume at final report |
+
+On re-invocation, detect the latest checkpoint and continue from the next step instead of restarting, unless the user asks for a fresh run.
+
+## Dry-Run Mode
+
+If the user asks for dry run, preview, or plan-only execution:
+- Generate the impact report
+- Select delivery mode
+- Show files likely to change and why
+- Run safe current-state checks such as type/lint/test discovery
+- Do not edit product code
+- Write a pre-flight report under `.engineering-intelligence/reports/`
 
 ## Environmental Backpressure
 
@@ -136,6 +173,8 @@ AI-DLC: <phase> -> <stage> -> <status>
 - [ ] Brownfield reverse engineering exists before broad changes
 - [ ] Requirements and execution plan are durable files
 - [ ] Construction is split into explicit units
+- [ ] Unit dependency graph exists in `execution-plan.md`
 - [ ] Cross-unit discoveries are loaded and updated
+- [ ] Checkpoints are written and resume is supported
 - [ ] Validation uses environmental backpressure
 - [ ] Operations readiness is addressed when deployment or production behavior changes

package/templates/canonical/skills/api-backward-compatibility-engine/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: api-backward-compatibility-engine
+description: Diffs API contracts, classifies changes as additive, deprecated, or breaking, and requires versioning or migration notes for breaking changes.
+version: 1.0.0
+---
+
+# API Backward Compatibility Engine
+
+Use this skill when routes, handlers, request schemas, response schemas, GraphQL schemas, RPC contracts, events, SDKs, webhooks, or public service interfaces change.
+
+## Procedure
+
+1. **Load Current API Contract**
+   - `knowledge-base/04-api-documentation.md`
+   - OpenAPI / Swagger specs
+   - GraphQL schemas
+   - Protobuf / gRPC definitions
+   - Route files, request validators, response serializers
+   - Event schema registries or webhook docs
+
+2. **Diff Proposed Or Actual Change**
+   - Endpoints added/removed/renamed
+   - Methods changed
+   - Request fields added/removed/renamed/type-changed
+   - Response fields added/removed/renamed/type-changed
+   - Auth/permission requirements changed
+   - Error codes/status codes changed
+   - Pagination, sorting, idempotency, or rate-limit semantics changed
+
+3. **Classify Each Change**
+   - `additive`: backward-compatible addition
+   - `deprecated`: old behavior still works but has deprecation path
+   - `breaking`: existing clients can fail or observe incompatible semantics
+
+4. **Require Versioning For Breaking Changes**
+   - Require explicit version bump, migration notes, or recorded human approval.
+   - Block change finalization if breaking changes lack versioning/migration documentation.
+
+5. **Generate Compatibility Notes**
+   - Update API docs and change record.
+   - Identify impacted tests and client contracts.
+
+## Output
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/api-compatibility.md`:
+
+```markdown
+# API Backward Compatibility: <unit>
+
+## Contract Sources
+- <path>
+
+## Change Classification
+| API Surface | Change | Class | Client Impact | Required Action |
+|---|---|---|---|---|
+
+## Breaking Changes
+- <change>
+- Version bump: <path/evidence or missing>
+- Migration notes: <path/evidence or missing>
+
+## Validation
+- Contract tests:
+- Snapshot/replay checks:
+- Manual verification:
+```
+
+## Blocking Conditions
+
+- Breaking change without version bump, migration notes, or explicit approval
+- Removed API without deprecation path
+- Response contract changed without compatibility test
+- Auth requirement changed without security/permission test
+
+## Quality Gates
+
+- [ ] Contract sources were loaded
+- [ ] Every API change is classified as additive, deprecated, or breaking
+- [ ] Breaking changes have version bump or explicit approval
+- [ ] API docs and tests are updated for contract changes

package/templates/canonical/skills/api-snapshot-testing-engine/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: api-snapshot-testing-engine
+description: Captures pre-change API request/response snapshots, replays them post-change, and flags semantic response regressions.
+version: 1.0.0
+---
+
+# API Snapshot Testing Engine
+
+Use this skill when an API endpoint, route handler, controller, serializer, GraphQL resolver, RPC method, webhook, or response-shaping code changes.
+
+## Snapshot Root
+
+Store snapshots under:
+
+```text
+.engineering-intelligence/snapshots/
+```
+
+## Procedure
+
+1. **Select Snapshot Scenarios**
+   - Read `knowledge-base/04-api-documentation.md`, `service-graph.json`, route files, and existing API tests.
+   - Select representative requests for changed endpoints:
+     - happy path
+     - auth failure
+     - validation error
+     - downstream timeout or dependency failure
+     - edge-case response shape
+
+2. **Capture Pre-Change Snapshots**
+   - Before implementation edits when feasible, capture pre-change request/response pairs.
+   - If runtime capture is unavailable, extract examples from existing tests or API docs and mark confidence accordingly.
+
+3. **Replay Post-Change**
+   - After implementation, replay the same requests against the changed code or test harness.
+   - Diff status code, headers that are part of the contract, response shape, computed values, pagination metadata, error format, and auth behavior.
+
+4. **Classify Differences**
+   - `expected`: intentional change covered by acceptance criteria or API compatibility notes
+   - `compatible`: additive or non-contractual difference
+   - `regression-candidate`: semantic difference that may break callers
+   - `breaking`: incompatible response or status change without approval
+
+5. **Block On Unexplained Regressions**
+   - `regression-candidate` and `breaking` diffs block Definition of Done until resolved, approved, or recorded as open risk.
+
+## Output
+
+Write `.engineering-intelligence/snapshots/<unit>/snapshot-report.md`:
+
+```markdown
+# API Snapshot Report: <unit>
+
+## Snapshot Sources
+- pre-change: <runtime|test fixture|documentation|unavailable>
+- post-change: <runtime|test fixture|unavailable>
+
+## Replay Results
+| Scenario | Endpoint | Pre-Change | Post-Change | Classification | Evidence |
+|---|---|---|---|---|---|
+
+## Blocking Differences
+- <regression or breaking difference>
+
+## Approval / Rationale
+- <expected difference and evidence>
+```
+
+## Quality Gates
+
+- [ ] Changed API surfaces have snapshot scenarios or explicit unavailable rationale
+- [ ] Pre-change snapshots are captured before implementation when feasible
+- [ ] Post-change replay was performed or blocked with evidence
+- [ ] Semantic differences are classified
+- [ ] Unexplained regression candidates block completion

package/templates/canonical/skills/context-budget-optimizer/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: context-budget-optimizer
+description: Minimizes AI IDE token usage by ranking, slicing, summarizing, and lazy-loading project intelligence while preserving required gates and output quality.
+version: 1.0.0
+---
+
+# Context Budget Optimizer
+
+Use this skill before broad intelligence reads in implementation, analysis, review, and synchronization workflows. The goal is to produce the same engineering output with fewer tokens by loading only the most relevant evidence.
+
+## Token Budget Policy
+
+Default budget allocation:
+
+| Budget Area | Target |
+|---|---:|
+| Intelligence context | <= 40% |
+| Source/test snippets | 30% |
+| Tool diagnostics | 20% |
+| User interaction and final answer | 10% |
+
+If the AI IDE exposes a context-window size, estimate against that. If not, use relative budgets and prefer compact artifacts over full documents.
+
+## Context Manifest
+
+Before loading full documents, create or update:
+
+```text
+.engineering-intelligence/context/context-manifest.md
+```
+
+Format:
+
+```markdown
+# Context Manifest
+
+## Scope
+- Request:
+- Candidate modules:
+- Risk:
+
+## Ranked Context
+| Rank | Artifact | Sections / Keys | Reason | Estimated Tokens | Load Mode |
+|---:|---|---|---|---:|---|
+| 1 | `.engineering-intelligence/context/module-map.md` | auth row | direct scope | 120 | slice |
+| 2 | `knowledge-base/04-api-documentation.md` | H2: Auth API | API contract | 500 | section |
+```
+
+## Procedure
+
+1. **Resolve Scope**
+   - Use the user request, changed files, graph proximity, and impact report.
+   - Identify candidate modules, services, APIs, schemas, tests, and risk areas.
+
+2. **Rank Artifacts**
+   - Load compact maps first: context maps, graph node summaries, `aidlc-state.md`, active unit, acceptance criteria.
+   - Rank knowledge docs by graph proximity and section confidence.
+   - Prefer H2 sections with high/medium confidence.
+   - Penalize stale or low-confidence sections unless they are required for risk.
+
+3. **Slice Before Full Read**
+   - Load only relevant H2 sections, table rows, graph nodes/edges, and file snippets.
+   - Do not load an entire knowledge document when a section or table row is enough.
+   - Do not load all skills. Invoke only skills triggered by the current change.
+
+4. **Lazy Loading**
+   - Defer expensive artifacts until a gate requires them.
+   - Examples:
+     - Load API docs only when API surfaces are touched.
+     - Load migration docs only when schema/persistence changes.
+     - Load security assessment only for security-sensitive paths.
+     - Load snapshots only when API replay applies.
+
+5. **Summarize And Cache**
+   - Write compact summaries to `.engineering-intelligence/context/context-manifest.md`.
+   - Store pointers to source evidence instead of copying long excerpts.
+   - Reuse manifest rankings during resume/checkpoint flows.
+
+6. **Escalate When Budget Is Insufficient**
+   - If critical context cannot fit, stop and report what was excluded, why it matters, and whether the user wants a narrower scope.
+
+## Rules
+
+- Never sacrifice required safety gates to save tokens.
+- Prefer evidence pointers over pasted content.
+- Prefer graph node/edge slices over full graph JSON.
+- Prefer section-level confidence metadata over full-document reads.
+- Keep initial intelligence loading under 40% of context budget whenever possible.
+- Lazy Loading is mandatory for large projects.
+
+## Quality Gates
+
+- [ ] Context Manifest exists for non-trivial workflows
+- [ ] Ranked context explains why each artifact was loaded
+- [ ] Initial context stayed within 40% budget or escalation was recorded
+- [ ] Full documents were avoided when slices were enough
+- [ ] Required gates still had enough evidence to run

package/templates/canonical/skills/context-sync-engine/SKILL.md

@@ -84,29 +84,48 @@ Queue → Worker → Process → DB Write → Notify
 | stripe | 12.x | payments module | Medium — breaking changes |
 ```
 
+### `context-manifest.md` — Token Budget And Relevance Plan
+
+```markdown
+# Context Manifest
+
+| Rank | Artifact | Sections / Keys | Reason | Estimated Tokens | Load Mode |
+|---:|---|---|---|---:|---|
+```
+
 ## Procedure
 
-1. **Check Impact** — Review the impact report and graph updates. Identify which context maps are affected.
+1. **Context Relevance Selection** — Use `context-budget-optimizer` before reading broad intelligence. Rank knowledge and context documents by graph proximity to the change scope:
+   - direct graph neighbors first
+   - critical-path maps next
+   - impacted API/schema/security docs next
+   - broad background docs last
+   Estimate token cost and load in relevance order until roughly 40% of the available context budget is consumed. Reserve the rest for implementation, tests, diagnostics, and user interaction. If critical docs cannot fit, escalate with the missing docs and reason.
+   Write the ranking to `.engineering-intelligence/context/context-manifest.md`.
+
+2. **Check Impact** — Review the impact report and graph updates. Identify which context maps are affected.
 
-2. **Update Affected Maps** — For each affected map:
+3. **Update Affected Maps** — For each affected map:
    - Update specific entries, not the entire map
    - Add new entries for new modules/services/paths
    - Remove entries for deleted modules/services
    - Update paths and descriptions for renamed elements
 
-3. **Preserve Conciseness** — Each map should be:
+4. **Preserve Conciseness** — Each map should be:
    - Under 150 lines
    - Table-formatted where possible
    - Navigational (paths and quick descriptions), not explanatory
    - Optimized for AI agent context windows
 
-4. **Verify Accuracy** — Cross-check updated maps against:
+5. **Verify Accuracy** — Cross-check updated maps against:
    - Current `.engineering-intelligence/graph/` data
    - Actual file system paths (do they still exist?)
 
 ## Rules
 
 - Keep context concise and navigational — not a knowledge-base duplicate
+- Load context by relevance, not by directory order
+- Keep initial intelligence loading under 40% of the available context budget when possible
 - Use tables over prose wherever possible
 - Update only affected maps from the impact report
 - Do not regenerate unrelated context
@@ -115,6 +134,9 @@ Queue → Worker → Process → DB Write → Notify
 ## Quality Gates
 
 - [ ] Each map is under 150 lines
+- [ ] Relevant docs were ranked by graph proximity before broad loading
+- [ ] `context-manifest.md` was updated for non-trivial work
+- [ ] Context budget was preserved or an escalation was recorded
 - [ ] Updated entries reference real, existing paths
 - [ ] Only impact-affected maps were modified
 - [ ] Table format used where appropriate

package/templates/canonical/skills/contract-test-generator/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: contract-test-generator
+description: Generates consumer-driven contract test stubs for service boundaries based on API contracts and service graph topology.
+version: 1.0.0
+---
+
+# Contract Test Generator
+
+Use this skill when service boundaries, API clients, webhooks, events, GraphQL schemas, or RPC contracts change.
+
+## Procedure
+
+1. Read `service-graph.json`, `knowledge-base/04-api-documentation.md`, OpenAPI/GraphQL/protobuf schemas, and existing contract tests.
+2. Detect the project’s contract-test framework if any: Pact, Spring Cloud Contract, protobuf conformance tests, schema snapshots, custom integration harness, or plain test framework.
+3. Generate or recommend stubs matching the project’s exact test structure and assertion style.
+4. Cover canonical scenarios:
+   - happy path
+   - auth failure
+   - validation error
+   - downstream timeout
+   - unexpected response shape
+5. Feed generated stubs and commands into `testing-intelligence-engine`.
+
+## Output
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/contract-test-plan.md`:
+
+```markdown
+# Contract Test Plan: <unit>
+
+| Boundary | Consumer | Provider | Scenario | Stub/Test Path | Status |
+|---|---|---|---|---|---|
+```
+
+## Quality Gates
+
+- [ ] Changed service boundaries are identified
+- [ ] Existing contract-test style is matched
+- [ ] Canonical failure scenarios are covered or explicitly not applicable
+- [ ] Contract tests are linked to acceptance criteria

package/templates/canonical/skills/convention-detector/SKILL.md

@@ -121,6 +121,19 @@ This capability does not modify product code.
    - **Exceptions**: specific files or modules that deviate (and possible reasons)
    - **Confidence**: how certain the detection is (based on sample size)
 
+   ## Convention Severity
+
+   Classify violations with these blocking rules:
+
+   | Severity | Meaning | Completion Rule |
+   |---|---|---|
+   | `critical` | Violates architectural boundary, security convention, data access rule, public API shape, or framework lifecycle rule | Blocks completion |
+   | `major` | Breaks dominant project structure, error handling, logging, import style, or test pattern in a way that creates maintenance risk | Must fix or record review finding |
+   | `minor` | Local naming/order/style mismatch that is mechanically fixable | Auto-correct when safe |
+   | `exception` | Existing legacy or documented exception | Record but do not block |
+
+   A pattern must exceed `>70%` adherence to be treated as a convention. Structural means the violation changes file placement, layer ownership, dependency direction, API envelope, persistence access, or lifecycle hook usage rather than simple naming.
+
 10. **Write conventions document** — Generate `knowledge-base/16-conventions.md` following the output format below.
 
 11. **Enhance coding patterns memory** — Update `.engineering-intelligence/memory/coding-patterns.md` with durable conventions that are unlikely to change.
@@ -167,8 +180,8 @@ Sample size: <N files analyzed across M modules>
 
 ## Convention Violations
 
-| Convention | Violation | Location | Severity |
-|---|---|---|---|
+| Convention | Violation | Location | Severity | Blocks Completion | Recommended Action |
+|---|---|---|---|---|---|
 | ... | ... | ... | ... |
 ```
 
@@ -185,6 +198,7 @@ Add a `## Conventions` section with only durable patterns that pass the durabili
 - [ ] Git conventions are extracted from actual git history (not assumed)
 - [ ] Each convention has an adherence rate and evidence citation
 - [ ] Exceptions to conventions are listed (not hidden)
+- [ ] Convention violations include severity and blocking decision
 - [ ] `knowledge-base/16-conventions.md` exists and follows the output format
 - [ ] `coding-patterns.md` is enhanced with a Conventions section
 - [ ] Only patterns with >70% adherence are classified as conventions

package/templates/canonical/skills/database-migration-safety-engine/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: database-migration-safety-engine
+description: Reviews database migrations for backward compatibility, rollback coverage, locks, destructive operations, and production-dangerous changes.
+version: 1.0.0
+---
+
+# Database Migration Safety Engine
+
+Use this skill whenever schemas, migrations, ORM models, data stores, indexes, or persistence contracts change.
+
+## Procedure
+
+1. **Detect Migration System**
+   - Prisma, Drizzle, TypeORM, Sequelize, Alembic, Django migrations, Rails migrations, Flyway, Liquibase, Knex, raw SQL, Terraform-managed database resources.
+
+2. **Classify Operations**
+   - Additive: new nullable column, new table, additive index
+   - Backward-compatible with caution: new non-null column with default, enum expansion, trigger change
+   - Dangerous: column/table drop, rename without compatibility window, type narrowing, destructive data rewrite, full table lock, index without `CONCURRENTLY` for PostgreSQL production tables
+   - Irreversible: data deletion, lossy transform, externalized state mutation
+
+3. **Validate Rollback**
+   - Check for a down migration or rollback equivalent.
+   - Generate down migration stubs when missing, but mark them for human review.
+   - Record irreversible steps explicitly.
+
+4. **Check Zero-Downtime Safety**
+   - Prefer expand/contract migrations.
+   - Require deprecation windows for drops/renames.
+   - Require online index creation where supported, such as PostgreSQL `CREATE INDEX CONCURRENTLY`.
+   - Require explicit approval for production-dangerous operations.
+
+5. **Map Query Impact**
+   - Parse ORM model definitions and raw SQL strings.
+   - Build or update a schema-to-query map.
+   - Flag queries referencing changed columns/tables as directly impacted.
+
+## Output
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/database-migration-safety.md`:
+
+```markdown
+# Database Migration Safety: <unit>
+
+## Migration Files
+- <path>
+
+## Operation Classification
+| Operation | Object | Classification | Risk | Evidence |
+|---|---|---|---|---|
+
+## Rollback / Down Migration
+- Exists: <yes/no>
+- Stub generated: <yes/no>
+- Irreversible steps: <list or none>
+
+## Schema-To-Query Impact
+| Changed Schema Object | Query / ORM Usage | Impact | Evidence |
+|---|---|---|---|
+
+## Approval Required
+- <dangerous operation requiring explicit approval>
+```
+
+## Blocking Conditions
+
+- Missing down migration for medium-or-higher risk migration
+- Drop/rename without deprecation window
+- Full table lock risk not acknowledged
+- Production-dangerous operation without explicit approval
+- Changed column referenced by unupdated query
+
+## Quality Gates
+
+- [ ] Migration system was detected
+- [ ] Operations were classified
+- [ ] Down migration or rollback strategy exists
+- [ ] Schema-to-query impacts are listed
+- [ ] Explicit approval is recorded for dangerous operations

package/templates/canonical/skills/dead-code-detector/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: dead-code-detector
+description: Detects unused exports, unreachable code paths, zombie dependencies, and stale modules by combining static analysis with git history.
+version: 1.0.0
+---
+
+# Dead Code Detector
+
+Use this skill during initialization, major refactors, dependency cleanup, and technical-debt reviews.
+
+## Procedure
+
+1. Scan imports/exports, route registrations, job registrations, dependency injection containers, and public entry points.
+2. Identify unused exports, unreferenced files, unreachable branches, feature flags that are always on/off, and manifest dependencies with no import/use evidence.
+3. Cross-reference `git-intelligence-engine` for stale modules, low ownership, and no recent changes.
+4. Avoid false positives for framework-discovered files, reflection, migrations, generated code, and public package exports.
+5. Produce candidates, not automatic deletions.
+
+## Output
+
+Write or update `knowledge-base/12-technical-debt.md`:
+
+```markdown
+## Dead Code Candidates
+| Candidate | Type | Confidence | Evidence | Safe Removal Steps |
+|---|---|---|---|---|
+```
+
+## Quality Gates
+
+- [ ] Static references were checked
+- [ ] Framework dynamic entry points were considered
+- [ ] Git staleness was included
+- [ ] Findings include confidence and safe-removal steps

package/templates/canonical/skills/engineering-change-review/SKILL.md

@@ -67,6 +67,16 @@ Review completed engineering work for correctness, completeness, and alignment w
 | Change record | Does the CHG record accurately reflect the work? |
 | Impact report | Was the impact report referenced correctly? |
 
+### 6. Rollback Readiness
+
+| Check | What to Verify |
+|---|---|
+| Medium+ rollback | Medium, high, and critical risk changes include rollback instructions |
+| Data rollback | Migration rollback, compensating SQL, or irreversible approval is recorded |
+| Feature flags | Flag rollback is documented where applicable |
+| Infrastructure | IaC or deployment rollback is documented where applicable |
+| CHG alignment | CHG record rollback section matches operations readiness |
+
 ## Finding Severity Scale
 
 | Severity | Symbol | Meaning | Action Required |
@@ -80,7 +90,7 @@ Review completed engineering work for correctness, completeness, and alignment w
 ## Procedure
 
 1. **Read Context** — Load the impact report, implementation diff, and test results.
-2. **Review Each Dimension** — Walk through all five review dimensions above.
+2. **Review Each Dimension** — Walk through all six review dimensions above.
 3. **Score Findings** — Assign severity to each finding.
 4. **Check Intelligence** — Verify graph, knowledge, memory, and context were appropriately synced.
 5. **Write Report** — Generate the review report.
@@ -129,6 +139,11 @@ Write `.engineering-intelligence/reports/REV-XXX-<slug>.md`:
 
 ## Stale Intelligence Risks
 - <areas where docs may drift from code>
+
+## Rollback Readiness
+| Area | Status | Evidence |
+|---|---|---|
+| Code rollback | ✅/⚠️/❌ | <CHG or operations-readiness evidence> |
 ```
 
 ## Rules
@@ -141,7 +156,7 @@ Write `.engineering-intelligence/reports/REV-XXX-<slug>.md`:
 
 ## Quality Gates
 
-- [ ] All five review dimensions were evaluated
+- [ ] All six review dimensions were evaluated
 - [ ] Each finding has severity, location, and evidence
 - [ ] Test execution was verified (not assumed)
 - [ ] Intelligence sync status was checked