engineering-intelligence 0.2.0 → 0.4.0

package/templates/canonical/skills/initialize-intelligence-skill/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: initialize-intelligence-skill
+description: Initializes project engineering intelligence by analyzing repository evidence and generating knowledge, context, memory, event guidance, architecture graphs, and an initialization change record. Invoke when onboarding a repository or when asked to initialize engineering intelligence.
+version: 3.0.0
+---
+
+# Initialize Engineering Intelligence
+
+Create a trustworthy, evidence-backed project intelligence baseline. Analyze only artifacts present in source code, configuration, tests, infrastructure, and existing documentation. Mark unknowns and uncertainties explicitly — never invent architecture, APIs, schemas, or business rules.
+
+## Inputs
+
+- Repository root path (current working directory by default)
+- Optional: explicit scope constraints (monorepo package, service boundary)
+
+## Outputs
+
+Generate the following artifacts in order:
+
+### Knowledge Base (`knowledge-base/`)
+
+| Document | Purpose |
+|---|---|
+| `00-project-overview.md` | Name, purpose, tech stack, repo structure summary |
+| `01-repository-structure.md` | Directory tree, package boundaries, build artifacts |
+| `02-architecture.md` | Layers, modules, boundaries, communication patterns |
+| `03-runtime-flow.md` | Request lifecycle, startup, shutdown, async flows |
+| `04-api-documentation.md` | Routes, endpoints, GraphQL schemas, RPC interfaces |
+| `05-database.md` | Schemas, migrations, ORMs, data stores, caching |
+| `06-authentication.md` | Auth flows, session management, RBAC, tokens |
+| `07-frontend.md` | UI framework, routing, state management, components |
+| `08-backend.md` | Server framework, middleware, service patterns |
+| `09-infrastructure.md` | CI/CD, containers, cloud, deployment, environments |
+| `10-integrations.md` | Third-party APIs, SDKs, webhooks, message queues |
+| `11-complex-areas.md` | High-complexity modules, tricky logic, footguns |
+| `12-technical-debt.md` | Known debt, deprecated patterns, migration needs |
+| `13-onboarding.md` | Setup guide, dev workflow, common tasks |
+| `14-glossary.md` | Domain terms, abbreviations, naming conventions |
+| `15-validation-report.md` | Evidence audit of all claims made above |
+
+### Durable Memory (`.engineering-intelligence/memory/`)
+
+| Document | Content |
+|---|---|
+| `architecture-decisions.md` | ADRs, architectural choices, rationale |
+| `business-rules.md` | Domain rules, invariants, constraints from code |
+| `coding-patterns.md` | Recurring patterns, conventions, idioms |
+| `project-constraints.md` | Performance budgets, compatibility, regulatory |
+| `technology-decisions.md` | Stack choices, version policies, deprecation plans |
+
+### Navigation Context (`.engineering-intelligence/context/`)
+
+| Document | Content |
+|---|---|
+| `module-map.md` | Module names → paths → responsibilities |
+| `service-map.md` | Services → ports → protocols → dependencies |
+| `runtime-map.md` | Entry points → middleware chains → handlers |
+| `critical-paths.md` | Revenue, auth, data-integrity flows |
+| `dangerous-areas.md` | Fragile code, missing tests, race conditions |
+| `dependency-map.md` | External deps → internal consumers → risk |
+
+### Event Guidance (`.engineering-intelligence/events/`)
+
+| Document | Trigger |
+|---|---|
+| `api-changed.md` | When API routes, payloads, or contracts change |
+| `schema-changed.md` | When database schemas or migrations change |
+| `auth-changed.md` | When auth flows or permissions change |
+| `feature-added.md` | When new user-facing features are introduced |
+| `infrastructure-changed.md` | When CI, deployment, or infra config changes |
+
+### Architecture Graphs (`.engineering-intelligence/graph/`)
+
+| Artifact | Content |
+|---|---|
+| `dependency-graph.json` | Module/package dependency relationships |
+| `service-graph.json` | Service-to-service communication topology |
+| `runtime-graph.json` | Runtime call flows and middleware chains |
+| `business-flow-graph.json` | Business process flows across system boundaries |
+| `architecture-map.md` | Mermaid diagrams derived from JSON graphs |
+
+### Change History
+
+| Artifact | Content |
+|---|---|
+| `.changes/CHG-000-initialization.md` | Record of this initialization run |
+
+## Procedure
+
+1. **Discover** — Scan for: package manifests, workspace configs, runtimes (`package.json`, `go.mod`, `Cargo.toml`, `pyproject.toml`, etc.), build systems, entrypoints, CI configs, Dockerfiles, deployment manifests, environment examples, database schemas/migrations, API definitions, auth configs, test suites.
+
+2. **Trace Architecture** — Follow imports, dependency injection, middleware registration, route definitions, event handlers, and service boundaries. Map the critical runtime flows from code evidence, not assumptions.
+
+3. **Write Knowledge Base** — For each document:
+   - Open with a one-paragraph summary
+   - Back every material claim with a file path reference: `(evidence: path/to/file:L42)`
+   - Use `**Not detected**` for absent features, not silence
+   - Use `**Unclear from evidence** — [reason]` for ambiguous areas
+   - Use tables, code blocks, and structured lists — never prose walls
+
+4. **Validate Claims** — Re-read each knowledge document, check major claims against actual files, and write `15-validation-report.md` with findings categorized as: ✅ Supported, ⚠️ Partially Supported, ❌ Unsupported, ❓ Needs Human Review.
+
+5. **Generate Memory** — Extract only durable, long-lived decisions and patterns. Do NOT store transient implementation details. Each entry needs a `Source:` evidence reference.
+
+6. **Generate Context** — Create concise, navigational maps. Each map should fit in ~100 lines. Optimize for an AI agent quickly finding the right file, not for human reading.
+
+7. **Build Graphs** — Invoke `graph-engine` to produce all four JSON graphs and `architecture-map.md`. Every node and edge must have `evidence` and `confidence` fields.
+
+8. **Generate Events** — Write change-event guidance documents that describe what to check and update when specific types of changes occur.
+
+9. **Write History** — Create `CHG-000-initialization.md` with: timestamp, artifacts generated, confidence summary, areas needing human confirmation.
+
+10. **Report** — Summarize: total artifacts created, evidence coverage percentage estimate, high-confidence vs low-confidence areas, explicit list of items requiring human review.
+
+## Quality Gates
+
+- [ ] Every knowledge document has at least one evidence citation
+- [ ] No document contains invented implementation details
+- [ ] Validation report exists and covers all knowledge documents
+- [ ] All four graph JSON files validate against the graph-engine schema
+- [ ] Memory contains only durable, long-lived knowledge
+- [ ] Context maps are concise (< 150 lines each)
+- [ ] CHG-000 record exists and lists all generated artifacts
+
+## Cross-References
+
+- Uses: `deep-project-knowledge-extractor`, `knowledge-base-validator`, `graph-engine`, `change-history-engine`
+- Consumed by: `engineering-intelligence-skill`, all sync engines, `impact-analysis-engine`
+
+This initialization documents and validates the project. It does not implement product changes.

package/templates/canonical/skills/knowledge-base-validator/SKILL.md

@@ -1,17 +1,102 @@
 ---
 name: knowledge-base-validator
 description: Validates project knowledge documentation against source and configuration evidence, identifying stale, unsupported, or uncertain claims. Use after initialization or documentation synchronization.
+version: 3.0.0
 ---
 
 # Knowledge Base Validator
 
-Read `knowledge-base/*.md`, identify significant claims, and verify them against code, config, infrastructure, and tests.
+Systematically audit every significant claim in `knowledge-base/*.md` against actual repository evidence. Produce a structured validation report that identifies exactly what is supported, what is stale, and what needs human review.
 
-Write `knowledge-base/15-validation-report.md` with:
+## Inputs
 
-- supported, partially supported, unsupported, and unclear findings
-- evidence paths
-- confidence and stale-documentation risks
-- areas needing human review
+- Repository root path with `knowledge-base/` present
+- Optional: specific documents to validate (defaults to all)
 
-Do not silently rewrite other knowledge documents; update them only as part of an explicit synchronization workflow.
+## Procedure
+
+1. **Enumerate Claims** — Read each `knowledge-base/*.md` document. Extract every material claim about architecture, APIs, schemas, dependencies, configurations, flows, and behavior.
+
+2. **Verify Against Evidence** — For each claim, check:
+   - Does the referenced file/path still exist?
+   - Does the code at that location still support the claim?
+   - Has the relevant code changed since the claim was written?
+   - Are there new files/patterns that contradict the claim?
+
+3. **Categorize Findings** — Assign each finding a status:
+
+| Status | Symbol | Meaning |
+|---|---|---|
+| Supported | ✅ | Claim verified against current code |
+| Partially Supported | ⚠️ | Claim is partly true but missing nuance or outdated in some aspect |
+| Unsupported | ❌ | Claim contradicted by current code or evidence is missing |
+| Unclear | ❓ | Cannot determine accuracy — needs human review |
+| Stale | 🔄 | Claim references code that has changed significantly |
+
+4. **Assess Confidence** — For each document, calculate:
+   - Total claims examined
+   - Distribution across statuses
+   - Overall document confidence: High (>90% ✅), Medium (70-90% ✅), Low (<70% ✅)
+
+5. **Write Report** — Generate `knowledge-base/15-validation-report.md`
+
+## Output Format
+
+```markdown
+# Validation Report
+
+Generated: <ISO timestamp>
+Scope: <documents validated>
+
+## Summary
+
+| Document | Claims | ✅ | ⚠️ | ❌ | ❓ | Confidence |
+|---|---|---|---|---|---|---|
+| 00-project-overview.md | 12 | 10 | 1 | 0 | 1 | High |
+| ... | ... | ... | ... | ... | ... | ... |
+
+## Detailed Findings
+
+### 00-project-overview.md
+
+#### ✅ Supported
+- "Uses Express.js 4.18" (evidence: package.json:L15)
+
+#### ⚠️ Partially Supported
+- "PostgreSQL is the primary database" — true, but Redis is also used for caching (evidence: docker-compose.yml:L22)
+
+#### ❌ Unsupported
+- "Uses Passport.js for auth" — no Passport dependency found; appears to use custom JWT middleware (evidence: package.json, src/middleware/auth.ts)
+
+#### ❓ Needs Human Review
+- "Supports multi-tenancy" — tenant isolation code exists but completeness is unclear
+
+## Stale Documentation Risks
+
+- <areas where code has diverged from docs>
+
+## Recommended Actions
+
+- <specific documents needing update>
+- <claims needing human confirmation>
+```
+
+## Rules
+
+- Do NOT silently rewrite knowledge documents during validation
+- Update knowledge documents only as part of an explicit synchronization workflow
+- Report honestly — a low-confidence score is valuable information
+- Flag areas where you lack sufficient context to validate
+
+## Quality Gates
+
+- [ ] Every knowledge document (00-14) is covered in the report
+- [ ] Each finding has an evidence path or explicit "no evidence found"
+- [ ] Summary table has accurate counts
+- [ ] Stale documentation risks are identified
+- [ ] Recommended actions are actionable
+
+## Cross-References
+
+- Used by: `initialize-intelligence-skill`, `incremental-sync-engine`
+- Depends on: `deep-project-knowledge-extractor` (produces the docs to validate)

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

@@ -1,17 +1,86 @@
 ---
 name: knowledge-sync-engine
 description: Incrementally synchronizes the project knowledge base after code changes, updating only documents affected by verified behavior changes. Use after implementation or architectural decisions.
+version: 3.0.0
 ---
 
 # Knowledge Synchronization
 
-Use the persisted impact report and actual diff to update only affected documents:
+Update only the knowledge-base documents affected by a verified behavior change. Preserve accurate existing content — never regenerate entire documents.
 
-- API behavior: `knowledge-base/04-api-documentation.md`
-- persistence/schema: `knowledge-base/05-database.md`
-- authentication/authorization: `knowledge-base/06-authentication.md`
-- runtime flow: `knowledge-base/03-runtime-flow.md`
-- architecture: `knowledge-base/02-architecture.md`
-- frontend/backend/infrastructure/integrations: corresponding knowledge documents
+## Inputs
 
-Preserve accurate existing detail and attach evidence for changed claims.
+- Persisted impact report (`.engineering-intelligence/reports/IMP-XXX-*.md`)
+- Actual diff or change record showing what changed
+- Current `knowledge-base/` documents
+
+## Document-to-Change Mapping
+
+| Change Category | Primary Document | Also Check |
+|---|---|---|
+| API routes, endpoints, payloads | `04-api-documentation.md` | `03-runtime-flow.md` |
+| Database schema, migrations | `05-database.md` | `02-architecture.md` |
+| Auth flows, permissions | `06-authentication.md` | `03-runtime-flow.md`, `11-complex-areas.md` |
+| Frontend components, routing | `07-frontend.md` | `01-repository-structure.md` |
+| Backend services, middleware | `08-backend.md` | `03-runtime-flow.md` |
+| CI/CD, deployment, hosting | `09-infrastructure.md` | — |
+| Third-party integrations | `10-integrations.md` | `01-repository-structure.md` |
+| New complex logic | `11-complex-areas.md` | — |
+| Debt introduced or resolved | `12-technical-debt.md` | — |
+| Dev workflow changes | `13-onboarding.md` | — |
+| New domain terms | `14-glossary.md` | — |
+| Architecture changes | `02-architecture.md` | `01-repository-structure.md`, `03-runtime-flow.md` |
+| New packages or modules | `01-repository-structure.md` | `02-architecture.md` |
+| Project overview changes | `00-project-overview.md` | — |
+
+## Procedure
+
+1. **Read Impact Report** — Identify which knowledge documents are flagged as affected.
+
+2. **Read Affected Documents** — Load only the documents identified in step 1.
+
+3. **Identify Stale Sections** — For each affected document, find the specific sections that reference changed code, APIs, schemas, or behavior.
+
+4. **Update Sections** — For each stale section:
+   - Rewrite with current, accurate information
+   - Add evidence citations: `(evidence: path/to/file:L42)`
+   - Mark uncertain areas: `**Unclear from evidence** — [reason]`
+   - Preserve all unaffected content exactly as-is
+
+5. **Verify Consistency** — Check that updated sections don't contradict other sections in the same document or other knowledge documents.
+
+## Evidence Attachment Format
+
+Every changed claim must include an evidence citation:
+
+```markdown
+The auth middleware now validates JWT tokens using RS256 algorithm
+(evidence: src/middleware/auth.ts:L15-L28)
+```
+
+For removed features:
+```markdown
+~~OAuth2 PKCE flow support~~ — Removed in CHG-015
+(evidence: git diff, src/auth/oauth.ts deleted)
+```
+
+## Rules
+
+- Update only documents and sections identified by the impact report
+- Preserve all accurate existing content unchanged
+- Attach evidence for every changed claim
+- Never regenerate entire documents during incremental sync
+- If unsure whether a claim is stale, flag it rather than silently rewriting
+
+## Quality Gates
+
+- [ ] Only impact-identified documents were modified
+- [ ] Changed sections have evidence citations
+- [ ] Accurate existing content was preserved
+- [ ] No documents were fully regenerated
+
+## Cross-References
+
+- Depends on: `impact-analysis-engine` (identifies affected documents)
+- Used by: `incremental-sync-engine`, `engineering-intelligence-skill`
+- Related: `knowledge-base-validator` (validates after sync)

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

@@ -1,18 +1,80 @@
 ---
 name: memory-sync-engine
 description: Maintains durable engineering memory after architecture, business rule, constraint, convention, or technology decisions change. Use only for long-lived knowledge.
+version: 3.0.0
 ---
 
 # Memory Synchronization
 
-Maintain `.engineering-intelligence/memory/`:
+Maintain durable, long-lived engineering memory. Memory is for decisions and patterns that persist across many changes — never for transient implementation details.
 
-- `architecture-decisions.md`
-- `business-rules.md`
-- `coding-patterns.md`
-- `project-constraints.md`
-- `technology-decisions.md`
+## Inputs
 
-Do not store transient implementation notes or unverified assumptions as durable memory.
+- Impact report and actual change evidence
+- Current `.engineering-intelligence/memory/` documents
 
-Use the associated impact report and actual change evidence to decide whether durable memory is affected. Leave memory unchanged when no long-lived decision, rule, constraint, pattern, or technology choice changed.
+## Memory Categories
+
+| Document | Content | Update Trigger |
+|---|---|---|
+| `architecture-decisions.md` | ADRs, layer definitions, boundary rules, communication patterns | Architecture changes, new service boundaries, pattern adoptions |
+| `business-rules.md` | Domain invariants, validation rules, business logic constraints | Business logic changes, regulatory updates |
+| `coding-patterns.md` | Recurring conventions, idioms, naming rules, file organization | Refactors that establish new patterns, convention changes |
+| `project-constraints.md` | Performance budgets, compatibility requirements, SLA targets, regulatory | Infrastructure changes, new compliance requirements |
+| `technology-decisions.md` | Stack choices, framework versions, deprecation timelines, migration plans | Dependency updates, technology migrations |
+
+## Staleness Detection Rules
+
+A memory entry may be stale if:
+
+1. **Referenced code no longer exists** — The decision references files/modules that were deleted or renamed
+2. **Contradicted by current code** — The pattern described is no longer followed in the codebase
+3. **Superseded by new decision** — A newer decision overrides the documented one
+4. **Evidence outdated** — The evidence citations point to significantly changed code
+
+## Procedure
+
+1. **Check Trigger** — Review the impact report. Does the change affect a durable decision, rule, constraint, pattern, or technology choice? If not, **stop — leave memory unchanged**.
+
+2. **Identify Affected Entries** — Match the change against memory categories above. Only proceed for matching categories.
+
+3. **Update Entry** — For each affected entry:
+   ```markdown
+   ## <Decision/Pattern Title>
+
+   **Status**: Active | Superseded | Deprecated
+   **Decided**: <date or CHG reference>
+   **Last verified**: <date>
+
+   <Description of the decision/pattern>
+
+   **Rationale**: <why this was chosen>
+   **Source**: (evidence: path/to/file)
+   **Alternatives considered**: <if applicable>
+   ```
+
+4. **Verify Durability** — Before adding a new memory entry, confirm it's truly durable:
+   - Will this still be relevant after 5+ more changes?
+   - Is this a decision or just an implementation detail?
+   - Is this captured better elsewhere (knowledge-base, context)?
+
+## Rules
+
+- **Durable only**: Do not store transient implementation notes or unverified assumptions
+- **Evidence required**: Every entry must cite source evidence
+- **Leave unchanged when appropriate**: Most changes do NOT affect durable memory — it's correct to update nothing
+- **Status tracking**: Mark superseded decisions as `Superseded` rather than deleting them — history matters
+- **No product code**: Memory synchronization never modifies product code
+
+## Quality Gates
+
+- [ ] Change was verified to affect durable knowledge before updating
+- [ ] Only affected entries were modified
+- [ ] New entries are truly durable (not transient implementation details)
+- [ ] All entries have evidence citations
+- [ ] Superseded entries are marked, not deleted
+
+## Cross-References
+
+- Used by: `incremental-sync-engine`, `engineering-intelligence-skill`
+- Consumed by: `engineering-orchestrator` (for routing decisions), `change-agent` (for pattern compliance)

package/templates/canonical/skills/refactoring-planner/SKILL.md

@@ -1,10 +1,151 @@
 ---
 name: refactoring-planner
 description: Plans safe refactors by identifying dependencies, migration steps, validation needs, compatibility risk, and rollback strategy. Use before non-trivial refactors.
+version: 3.0.0
 ---
 
 # Refactoring Planner
 
-Identify duplicated logic, unsafe coupling, large or fragile areas, migration boundaries, and tests required to preserve behavior.
+Plan safe, incremental refactoring with clear migration steps, validation checkpoints, and rollback strategies.
 
-For significant proposals, write `knowledge-base/18-refactor-plan.md` with motivation, affected areas, migration steps, risk controls, validation, and rollback guidance.
+## Inputs
+
+- Refactoring goal (described by user or identified by architecture review)
+- `.engineering-intelligence/graph/` (dependency relationships)
+- `knowledge-base/12-technical-debt.md` (existing debt)
+- `.engineering-intelligence/memory/architecture-decisions.md` (constraints)
+
+## Refactoring Categories
+
+| Category | Examples | Risk Level |
+|---|---|---|
+| **Extract** | Extract module, service, function, interface | Medium |
+| **Rename** | Rename module, restructure directories | Low–Medium |
+| **Consolidate** | Merge duplicate logic, unify patterns | Medium |
+| **Decouple** | Break circular deps, introduce interfaces | Medium–High |
+| **Migrate** | Change framework, database, language version | High |
+| **Restructure** | Redefine boundaries, change architecture pattern | High–Critical |
+
+## Risk Scoring
+
+| Factor | Low (1) | Medium (2) | High (3) | Critical (4) |
+|---|---|---|---|---|
+| **Scope** | 1–3 files | 4–10 files | 10–25 files | 25+ files |
+| **Dependents** | 0–2 consumers | 3–5 consumers | 6–10 consumers | 10+ consumers |
+| **Test coverage** | Well-tested | Partial | Sparse | None |
+| **Data impact** | None | Read-only paths | Write paths | Schema changes |
+| **Rollback** | Git revert | Multi-step | Complex | Irreversible |
+
+**Overall Risk** = max(all factors). If any factor is Critical, the refactor is Critical.
+
+## Procedure
+
+1. **Analyze Current State** — Using graphs and knowledge base:
+   - Map the exact scope of the refactor
+   - Identify all dependents of the code to be changed
+   - Note test coverage for affected areas
+   - Check for related technical debt
+
+2. **Design Target State** — Define:
+   - What the code should look like after refactoring
+   - New module/file structure (if changing boundaries)
+   - New interfaces or abstractions (if decoupling)
+   - Migration strategy for data (if applicable)
+
+3. **Plan Migration Steps** — Break into incremental, independently-deployable steps:
+   ```markdown
+   ### Step 1: <name>
+   - Changes: <what to modify>
+   - Validation: <how to verify this step>
+   - Rollback: <how to revert just this step>
+   - Dependencies: <what must be done first>
+   ```
+
+4. **Identify Validation Needs** — For each step:
+   - Existing tests that must pass
+   - New tests to add before refactoring
+   - Integration tests to verify behavior preservation
+   - Performance benchmarks (if applicable)
+
+5. **Define Rollback Strategy** — For the overall refactor:
+   - Can it be reverted with `git revert`?
+   - Are there data migrations that need reverse migrations?
+   - What's the point of no return?
+
+6. **Write Plan** — Generate `knowledge-base/18-refactor-plan.md`
+
+## Output Format
+
+```markdown
+# Refactoring Plan: <title>
+
+## Motivation
+<Why this refactor is needed — link to technical debt or architecture review>
+
+## Current State
+<What exists now, with file paths>
+
+## Target State
+<What should exist after, with proposed structure>
+
+## Risk Assessment
+| Factor | Rating | Justification |
+|---|---|---|
+| Scope | Medium | 8 files affected |
+| Dependents | High | 7 modules import the target |
+
+Overall Risk: **High**
+
+## Migration Steps
+
+### Step 1: Add new interface
+- Files: src/interfaces/auth.ts (new)
+- Validation: Type check passes
+- Rollback: Delete the file
+
+### Step 2: Implement adapter
+- Files: src/auth/adapter.ts (new)
+- Validation: Unit tests pass
+- Rollback: Delete the file, revert imports
+
+### Step 3: Migrate consumers (batch 1)
+- Files: src/routes/users.ts, src/routes/admin.ts
+- Validation: Integration tests pass
+- Rollback: Revert consumer changes
+
+## Validation Plan
+- [ ] All existing tests pass after each step
+- [ ] New tests added before behavior-preserving changes
+- [ ] Integration suite green after full migration
+
+## Rollback Strategy
+- Steps 1-3 are independently revertible via git
+- No data migrations required
+- Point of no return: None — fully reversible
+
+## Timeline Estimate
+- Step 1: ~30 minutes
+- Step 2: ~1 hour
+- Step 3: ~2 hours
+```
+
+## Rules
+
+- Never plan a refactor as a single big-bang change — break into steps
+- Each step must be independently verifiable
+- Add tests BEFORE making behavior-preserving changes
+- Consider backward compatibility during migration
+- This planning skill does not implement the refactor — it plans it
+
+## Quality Gates
+
+- [ ] All dependents are identified (not just direct consumers)
+- [ ] Each step has a validation and rollback strategy
+- [ ] Risk is scored with justification
+- [ ] Migration steps are ordered by dependency
+
+## Cross-References
+
+- Depends on: `graph-engine` (dependency data), `architecture-review-engine` (findings)
+- Used by: `engineering-intelligence-skill` (for refactor-type requests)
+- Triggers: `impact-analysis-engine` (when the refactor is implemented)