engineering-intelligence 1.3.0 → 1.5.0

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

@@ -32,15 +32,29 @@ Classify the incoming request before starting:
 
 ### 1. Pre-Flight: Read Intelligence
 
-Read these artifacts and identify relevant context:
-- `knowledge-base/` — architecture, APIs, runtime flow relevant to the change
-- `.engineering-intelligence/aidlc/` — active AI-DLC state, plan, audit, open questions, construction units
-- `.engineering-intelligence/memory/` — decisions, constraints, patterns that apply
-- `.engineering-intelligence/context/` — module map, critical paths, dangerous areas near the change
-- `.engineering-intelligence/graph/` — dependency and service relationships
+Use `context-budget-optimizer` before loading broad intelligence. Do not read all of `knowledge-base/` or all graph JSON by default. Build `.engineering-intelligence/context/context-manifest.md`, then load only relevant slices:
+- `knowledge-base/` — only H2 sections relevant to the changed modules, APIs, schemas, or risk areas
+- `.engineering-intelligence/aidlc/` — `aidlc-state.md`, active checkpoint, active unit, acceptance criteria, and execution-plan rows relevant to the request
+- `.engineering-intelligence/memory/` — only matching decisions, constraints, conventions, regression patterns, and ADR references
+- `.engineering-intelligence/context/` — module/service/runtime rows near the change scope
+- `.engineering-intelligence/graph/` — only relevant nodes/edges by graph proximity
 
 **If intelligence is missing or stale**: Run `initialize-intelligence-skill` first.
 
+Token rule: keep initial intelligence loading under 40% of the available context budget whenever possible. Lazy-load safety-gate evidence only when the trigger applies.
+
+#### Pre-Flight Freshness Gate
+
+Before impact analysis or code edits:
+
+1. Resolve the likely changed modules from the request, graph proximity, or `change-detection-engine`.
+2. Run `staleness-detector` scoped to those modules and related knowledge/context/memory artifacts.
+3. If any freshness score is below `60`, run `incremental-sync-engine` for the stale artifacts before editing product code, or explicitly mark stale context in the impact report with the affected documents and scores.
+4. If any score is below `50`, implementation is blocked until incremental sync runs or the user explicitly accepts stale-context risk.
+5. Use the `staleness-detector` **Pre-Implementation Drift Trigger** decision: `Proceed`, `Sync before implementation`, or `Block implementation`.
+6. Carry that exact decision into the impact report's freshness-gate line.
+7. Skip stale H2 sections that carry low confidence metadata unless they are refreshed or verified against source.
+
 ### 2. Impact Analysis: Write Report
 
 Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>.md`:
@@ -55,6 +69,7 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 
 ## Analysis
 - Mode: <proposal|diff>
+- Freshness gate: <passed|synced|stale risk accepted> with scores
 - Graph inputs consulted: <list>
 - Directly affected: <files, modules, services>
 - Indirectly affected: <downstream consumers, dependent services>
@@ -62,6 +77,10 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 
 ## Validation Requirements
 - <test types needed>
+- Type safety: <required|not applicable>
+- API compatibility: <required|not applicable>
+- Migration safety: <required|not applicable>
+- Acceptance mapping: required
 - <manual verification needed>
 
 ## Intelligence Artifacts Affected
@@ -94,9 +113,21 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 - Follow existing coding patterns from `.engineering-intelligence/memory/coding-patterns.md`
 - Read conventions from `knowledge-base/16-conventions.md` and `.engineering-intelligence/memory/coding-patterns.md` — match naming patterns, import style, error handling patterns, and code structure
 - If conventions document is missing or outdated, run `convention-detector` first
+- After generating or modifying each file, compare it against `coding-patterns.md` for naming, import order, error handling, logging, folder structure, test style, and framework idioms. Auto-correct minor violations. Structural convention violations become review findings and block completion when critical.
 - Respect architectural boundaries from `.engineering-intelligence/memory/architecture-decisions.md`
 - Consult `dangerous-areas.md` before modifying flagged code
 
+#### Strict TDD Red-Green Gate
+
+When TDD delivery mode is selected:
+
+1. Add or update the required tests first.
+2. Run the new/targeted tests before implementation code changes.
+3. Confirm they fail for the expected reason.
+4. Save failing output in `.engineering-intelligence/aidlc/construction/<unit>/build-and-test/build-and-test-summary.md`.
+5. Only then implement production code.
+6. If this sequence is skipped, mark the construction unit blocked unless the user explicitly approves non-TDD execution.
+
 ### 4. Add/Update Tests
 
 - Add tests proportional to the change risk level
@@ -110,10 +141,32 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 
 - Run linters, type checks, and test suites available in the project
 - Use environmental backpressure: analyze failed diagnostics, fix, and rerun the relevant command until it passes or a blocker is recorded
+- Run `type-safety-engine` for typed projects or record why no type system applies
+- Run `api-backward-compatibility-engine` when API, event, webhook, SDK, route, or schema contracts changed
+- Run `api-snapshot-testing-engine` when API response behavior can be replayed or sampled
+- Run `database-migration-safety-engine` when schema, ORM model, migration, index, or data persistence contracts changed
+- Run `security-audit-engine` in targeted dependency-risk mode when package manifests add or upgrade dependencies; critical CVEs block completion
+- Run `environment-variable-auditor` when environment variable reads, validation schemas, deployment config, or CI secrets change
+- Run `adr-compliance-checker` when accepted ADRs or architecture decisions apply to the changed area
+- Run `llm-prompt-injection-guard` when user-controlled data reaches prompts, RAG, agent tools, LLM calls, or durable AI memory
 - Write `.engineering-intelligence/aidlc/construction/<unit>/build-and-test/build-and-test-summary.md` for non-trivial units
 - **Never claim validation passed unless it actually ran and passed**
 - Record partial or failed validation honestly
 
+#### Acceptance Criteria Verification Matrix
+
+Before Definition of Done can pass, map every criterion from `.engineering-intelligence/aidlc/agile/acceptance-criteria.md` to evidence:
+
+```markdown
+## Acceptance Criteria Verification Matrix
+| Criterion | Evidence Type | Evidence | Result | Open Item |
+|---|---|---|---|---|
+| Given..., when..., then... | automated test | `test/file.test.ts` / command result | pass | — |
+| ... | manual verification | <steps required> | pending | <owner/reason> |
+```
+
+Missing mappings block the Done gate and must be copied into the CHG record as open items.
+
 ### 6. Incremental Sync
 
 Use `incremental-sync-engine` to update only affected artifacts:
@@ -148,6 +201,28 @@ Create `.changes/CHG-XXX-<summary>.md`:
 - <tests added/modified>
 - <test results: passed/failed/skipped>
 
+## Acceptance Criteria Verification
+<copy the Acceptance Criteria Verification Matrix, including open items>
+
+## Safety Gates
+- Freshness gate: <passed|synced|stale risk accepted>
+- Type safety: <passed|failed|not applicable>
+- API compatibility: <passed|failed|not applicable>
+- API snapshots: <passed|failed|not applicable>
+- Migration safety: <passed|failed|not applicable>
+- Dependency security: <passed|failed|not applicable>
+- Environment variables: <passed|failed|not applicable>
+- ADR compliance: <passed|failed|not applicable>
+- LLM prompt injection: <passed|failed|not applicable>
+- Convention enforcement: <passed|findings>
+
+## Rollback
+- Code rollback: <git revert command or branch rollback>
+- Data rollback: <down migration / compensating operation / N/A with justification>
+- Feature flag rollback: <toggle / N/A with justification>
+- Infrastructure rollback: <IaC rollback / N/A with justification>
+- Irreversible steps requiring approval: <list or none>
+
 ## Related Reports
 - IMP-XXX: <link to impact report>
 - REV-XXX: <link to review report, if applicable>
@@ -178,6 +253,7 @@ Summarize to the user:
 ## Quality Gates
 
 - [ ] Impact report written before any code edit
+- [ ] Pre-Flight Freshness Gate passed, synced stale artifacts, or stale risk was explicit in the impact report
 - [ ] All changed behavior has corresponding test coverage
 - [ ] Validation was actually executed (not just claimed)
 - [ ] Only affected intelligence artifacts were updated
@@ -185,6 +261,14 @@ Summarize to the user:
 - [ ] Story meets Definition of Ready before implementation starts
 - [ ] Story meets Definition of Done before final report
 - [ ] Acceptance criteria are mapped to validation evidence
+- [ ] Acceptance Criteria Verification Matrix has no unmapped criteria unless recorded as open items
+- [ ] Type safety, API compatibility, and migration safety gates ran when applicable
+- [ ] API snapshot replay ran for changed API behavior when feasible
+- [ ] Dependency security ran for new or upgraded packages
+- [ ] Environment variable audit ran when config/env usage changed
+- [ ] ADR compliance checked applicable accepted decisions
+- [ ] LLM prompt injection guard ran for LLM/user-input paths
+- [ ] Medium-and-above risk changes include rollback instructions or explicit N/A justification
 - [ ] Environmental backpressure was used for validation failures
 - [ ] Change record references the correct impact report
 - [ ] High-risk changes went through review gate
@@ -192,6 +276,6 @@ Summarize to the user:
 
 ## Cross-References
 
-- Depends on: `initialize-intelligence-skill` (prerequisite), `change-detection-engine`, `impact-analysis-engine`, `graph-engine`
-- Uses during execution: `testing-intelligence-engine`, `incremental-sync-engine`, `change-history-engine`
+- Depends on: `initialize-intelligence-skill` (prerequisite), `context-budget-optimizer`, `change-detection-engine`, `impact-analysis-engine`, `graph-engine`, `staleness-detector`
+- Uses during execution: `testing-intelligence-engine`, `api-snapshot-testing-engine`, `type-safety-engine`, `api-backward-compatibility-engine`, `database-migration-safety-engine`, `security-audit-engine`, `environment-variable-auditor`, `adr-compliance-checker`, `llm-prompt-injection-guard`, `incremental-sync-engine`, `change-history-engine`
 - Optional: `engineering-change-review` (for high-risk), `refactoring-planner` (for refactors), `convention-detector` (for convention compliance)

package/templates/canonical/skills/environment-variable-auditor/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: environment-variable-auditor
+description: Audits environment variable usage against examples, validation schemas, CI secrets, and deployment configuration.
+version: 1.0.0
+---
+
+# Environment Variable Auditor
+
+Use this skill when code adds, removes, or changes environment variables, configuration schemas, deployment manifests, or CI/CD secrets.
+
+## Procedure
+
+1. Detect environment variable reads:
+   - Node: `process.env.*`
+   - Python: `os.environ`, `os.getenv`
+   - Go: `os.Getenv`
+   - Ruby: `ENV[]`
+   - Java/Kotlin/C#: equivalent environment APIs
+2. Compare against `.env.example`, `.env.sample`, README setup docs, deployment manifests, CI secret declarations, and validation schemas such as Zod, envalid, pydantic, dotenv-safe, or custom config loaders.
+3. Flag:
+   - missing example entries
+   - missing validation/default
+   - stale example vars no longer used
+   - required vars not present in CI/deployment docs
+   - secrets accidentally committed or documented with real values
+4. Block completion for newly required production env vars without docs and validation.
+
+## Output
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/environment-variable-audit.md`:
+
+```markdown
+# Environment Variable Audit: <unit>
+
+| Variable | Usage | Example Present | Validation Present | Deployment/CI Present | Risk |
+|---|---|---|---|---|---|
+
+## Required Fixes
+- <missing or stale env handling>
+```
+
+## Quality Gates
+
+- [ ] Env reads were scanned
+- [ ] Example files and validation schemas were checked
+- [ ] CI/deployment declarations were checked when present
+- [ ] New required env vars are documented and validated

package/templates/canonical/skills/graph-engine/SKILL.md

@@ -70,6 +70,8 @@ Each JSON graph uses this envelope:
 | `configures` | Configuration dependency |
 | `implicit-dependency` | Shared database tables, shared config |
 | `event-coupling` | Event-driven coupling |
+| `imports-type` | Type-only or annotation-level dependency between interfaces, aliases, declarations, schemas, or annotations |
+| `co-change` | Git history coupling above confidence threshold |
 
 ### 2. `service-graph.json` — Service Communication Topology
 
@@ -102,6 +104,7 @@ Each JSON graph uses this envelope:
 | `service-layer` | Business logic service |
 | `repository` | Data access layer |
 | `background` | Background job or worker |
+| `function` | Function or method on a critical path |
 
 | Edge Relation | Description |
 |---|---|
@@ -136,6 +139,8 @@ Each JSON graph uses this envelope:
 | `store` | Persistence |
 | `sink` | Data output/consumer |
 | `validator` | Validation step |
+| `sensitive-source` | PII, token, payment, health, credential, or regulated data origin |
+| `sensitive-sink` | Sink that persists, transmits, logs, or exports sensitive data |
 
 | Edge Relation | Description |
 |---|---|
@@ -163,9 +168,13 @@ Derive Mermaid diagrams from the JSON graphs. Include:
 2. Build all five graphs from scratch
 3. Assign `verified` confidence to edges backed by explicit code evidence
 4. Assign `inferred` confidence to edges derived from patterns or naming conventions
-5. Integrate git change coupling data from `git-intelligence-engine` as `inferred` edges — files that frequently change together suggest hidden dependencies
-6. Mark unresolvable relationships as `unknown` and add to `unknowns` array
-7. Generate Mermaid diagrams in `architecture-map.md`
+5. Integrate git change coupling data from `git-intelligence-engine` as `co-change` edges when coupling strength is above `0.7`, confidence is `inferred`, and evidence cites commit ranges or reports
+6. Build `imports-type` edges from type checker/compiler API evidence when typed languages are detected
+7. Build function-level call graph nodes for critical paths in `runtime-graph.json`
+8. Annotate runtime edges with `metadata.hotness` derived from `critical-paths.md`, test coverage frequency, and git co-change strength
+9. Classify sensitive data nodes in `data-flow-graph.json` with `metadata.sensitivity` (`pii`, `token`, `payment`, `credential`, `health`, `regulated`, `none`) and track propagation to sinks
+10. Mark unresolvable relationships as `unknown` and add to `unknowns` array
+11. Generate Mermaid diagrams in `architecture-map.md`
 
 ### Incremental Mode (post-change update)
 
@@ -173,8 +182,9 @@ Derive Mermaid diagrams from the JSON graphs. Include:
 2. Identify affected nodes and edges across all graphs
 3. Update, add, or remove only affected nodes and edges
 4. Preserve stable node IDs — only change an ID if the represented element was renamed
-5. Re-derive affected sections of `architecture-map.md`
-6. Require full remapping only when structural impact cannot be bounded
+5. Update `imports-type`, `co-change`, function call, hotness, and sensitive data annotations where affected
+6. Re-derive affected sections of `architecture-map.md`
+7. Require full remapping only when structural impact cannot be bounded
 
 ## Rules
 
@@ -184,6 +194,8 @@ Derive Mermaid diagrams from the JSON graphs. Include:
 - Derive Mermaid diagrams in `architecture-map.md` from the JSON graph content — never hand-author diagrams that contradict the JSON
 - For ordinary changes, update only impacted nodes, edges, maps, and connected context documents
 - Rebuild all graphs on initialization, explicit mapping request, or when structural impact cannot be bounded
+- Do not add `co-change` edges below `0.7` coupling strength
+- Sensitive data propagation to unencrypted channels, logs, or unvalidated sinks must become a security finding in the impact report
 
 ## Quality Gates
 
@@ -192,6 +204,11 @@ Derive Mermaid diagrams from the JSON graphs. Include:
 - [ ] No `unknown` relationships are left out of the `unknowns` array
 - [ ] `architecture-map.md` Mermaid diagrams are syntactically valid
 - [ ] Node IDs are stable across incremental updates
+- [ ] Type dependencies are represented as `imports-type` where applicable
+- [ ] Co-change edges above `0.7` are represented or explicitly unavailable
+- [ ] Runtime critical paths include function-level nodes where detectable
+- [ ] Sensitive data nodes and propagation edges are annotated in `data-flow-graph.json`
+- [ ] Hot path edges include `metadata.hotness` when evidence exists
 
 ## Cross-References
 

package/templates/canonical/skills/impact-analysis-engine/SKILL.md

@@ -23,10 +23,13 @@ Determine what can break before changing code. Produce a reusable impact report
 3. **Trace Direct Impact** — Identify:
    - Files directly modified or proposed for modification
    - Functions, classes, types, and interfaces changed
+   - TypeScript interfaces, type aliases, enums, declaration files, Python annotations, Pydantic/dataclass models, and other typed contracts changed
    - API contracts affected (routes, request/response shapes)
    - Database schemas or migrations affected
    - Configuration changes
 
+   For typed languages, invoke `type-safety-engine` in dependency-tracing mode. Add type-only dependencies as `imports-type` edges in `dependency-graph.json` and include them in direct impact when the changed symbol is a shared type or annotation.
+
 4. **Trace Indirect Impact** — Using graph intelligence, identify:
    - Downstream consumers of changed modules (from dependency-graph)
    - Services communicating with changed services (from service-graph)
@@ -35,10 +38,14 @@ Determine what can break before changing code. Produce a reusable impact report
    - Data pipelines affected (from data-flow-graph)
    - Test suites covering affected code
    - Cross-reference with git change coupling data from `git-intelligence-engine` for hidden dependencies
+   - Query paths referencing changed schema fields from schema-to-query mapping
+   - API clients or contract tests affected by additive, deprecated, or breaking API changes
+
+5. **Traverse Sensitive Data Paths** — Query `data-flow-graph.json` for sensitive-source to sensitive-sink reachability involving the changed scope. Sensitive data propagation to unencrypted channels, logs, analytics events, prompt/RAG memory, or unvalidated sinks escalates risk and becomes a security finding in the impact report.
 
-5. **Trace Transitive Impact** — Follow 2nd and 3rd order effects through the graph. Identify files that are indirectly affected by consumers of the directly affected modules. Walk the dependency chain until impact attenuates or reaches a service boundary.
+6. **Trace Transitive Impact** — Follow 2nd and 3rd order effects through the graph. Identify files that are indirectly affected by consumers of the directly affected modules. Walk the dependency chain until impact attenuates or reaches a service boundary.
 
-6. **Score Risk** — Assign risk based on:
+7. **Score Risk** — Assign risk based on:
 
 | Factor | Low | Medium | High | Critical |
 |---|---|---|---|---|
@@ -48,8 +55,9 @@ Determine what can break before changing code. Produce a reusable impact report
 | **API contract** | None | Additive | Deprecated | Breaking |
 | **Test coverage** | Well-tested | Partial | Sparse | None |
 | **Change coupling** | None | Low (1-2 coupled files) | Medium (3-5 coupled files) | High (6+ coupled files) |
+| **Hot path** | Cold path | Normal | Critical path | Revenue/security/SLO path |
 
-7. **Identify Validation Needs** — Map impact to required validation:
+8. **Identify Validation Needs** — Map impact to required validation:
 
 | Impact Area | Validation Required |
 |---|---|
@@ -60,9 +68,9 @@ Determine what can break before changing code. Produce a reusable impact report
 | UI change | Visual regression, accessibility |
 | Infrastructure | Deploy to staging, smoke test |
 
-8. **Map Intelligence Artifacts** — Determine which intelligence artifacts need synchronization after the change is implemented.
+9. **Map Intelligence Artifacts** — Determine which intelligence artifacts need synchronization after the change is implemented.
 
-> **Surprise Impact Detection**: Flag any dependency discovered during analysis that is NOT in the current graph — these are surprise impacts that should be added to the graph. Surprise impacts indicate missing edges or nodes and must be reported in the Unknowns section of the impact report.
+> **Surprise Impact Detection**: Flag any dependency discovered during analysis that is NOT in the current graph. Submit the edge to `graph-engine` incremental mode as an `inferred` edge with evidence so the graph learns from the surprise. Surprise impacts must also be reported in the Unknowns section of the impact report until the graph update is complete.
 
 ## Output Format
 
@@ -83,9 +91,10 @@ Write `.engineering-intelligence/reports/IMP-XXX-<slug>.md`:
 - Missing: <graphs not available>
 
 ## Direct Impact
-| File/Module | Change Type | Risk |
-|---|---|---|
-| path/to/file.ts | Modified function `handleAuth` | high |
+| File/Module | Change Type | Dependency Type | Risk |
+|---|---|---|---|
+| path/to/file.ts | Modified function `handleAuth` | runtime call | high |
+| path/to/types.ts | Modified interface `User` | imports-type | high |
 
 ## Indirect Impact
 | Affected Area | Relationship | Confidence |
@@ -93,6 +102,13 @@ Write `.engineering-intelligence/reports/IMP-XXX-<slug>.md`:
 | UserService | Imports changed module | verified |
 | /api/users endpoint | Calls modified handler | inferred |
 
+## Contract And Data Impact
+| Surface | Classification | Required Gate |
+|---|---|---|
+| API <name> | additive | api-backward-compatibility-engine |
+| Table.column | schema-to-query impact | database-migration-safety-engine |
+| Sensitive data path | unencrypted sink | security-audit-engine |
+
 ## Risk Assessment
 - Overall risk: <level>
 - Key risk factors: <list>
@@ -130,13 +146,18 @@ Write `.engineering-intelligence/reports/IMP-XXX-<slug>.md`:
 - [ ] Scope is explicitly stated (not assumed)
 - [ ] Graph inputs are listed (consulted, refreshed, or missing)
 - [ ] Direct and indirect impact are separated
+- [ ] Type-level dependencies are traced for typed languages
+- [ ] API and schema/query impact are classified when relevant
+- [ ] Sensitive data path traversal was performed for data-flow changes
+- [ ] Surprise impacts were submitted to graph-engine incremental mode
 - [ ] Risk score is justified with evidence
 - [ ] Validation requirements are specific (not generic)
 - [ ] Report ends with the "did not modify product code" statement
 
 ## Cross-References
 
-- Depends on: `change-detection-engine`, `graph-engine`, `git-intelligence-engine`
+- Depends on: `change-detection-engine`, `graph-engine`, `git-intelligence-engine`, `type-safety-engine`
 - Consults: `data-flow-graph.json` (for data pipeline impact)
+- Consults: `api-backward-compatibility-engine`, `database-migration-safety-engine` when contracts or schemas change
 - Used by: `engineering-intelligence-skill`, `incremental-sync-engine`, `analyze-impact` workflow
 - Consumed by: `engineering-change-review`, `testing-intelligence-engine`

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

@@ -38,7 +38,11 @@ Systematically audit every significant claim in `knowledge-base/*.md` against ac
    - Distribution across statuses
    - Overall document confidence: High (>90% ✅), Medium (70-90% ✅), Low (<70% ✅)
 
-5. **Write Report** — Generate `knowledge-base/15-validation-report.md`
+5. **Cross-Document Consistency Check** — Extract key claims from all knowledge documents and compare claims across documents for contradictions, such as different framework versions, conflicting ownership, incompatible API signatures, or mismatched data model descriptions.
+
+6. **Auto-Heal Unsupported Claims** — During explicit synchronization workflows only, re-extract the smallest affected section for unsupported or stale claims, update that section with fresh evidence citations, and record the heal. Escalate claims requiring product judgment instead of guessing.
+
+7. **Write Report** — Generate `knowledge-base/15-validation-report.md`
 
 ## Output Format
 
@@ -75,6 +79,16 @@ Scope: <documents validated>
 
 - <areas where code has diverged from docs>
 
+## Cross-Document Contradictions
+
+| Claim A | Document A | Claim B | Document B | Suggested Canonical Resolution |
+|---|---|---|---|---|
+
+## Auto-Heal Actions
+
+| Document | Section | Action | Evidence | Result |
+|---|---|---|---|---|
+
 ## Recommended Actions
 
 - <specific documents needing update>
@@ -83,8 +97,8 @@ Scope: <documents validated>
 
 ## Rules
 
-- Do NOT silently rewrite knowledge documents during validation
-- Update knowledge documents only as part of an explicit synchronization workflow
+- Do NOT silently rewrite knowledge documents during read-only validation
+- Auto-heal unsupported claims only as part of an explicit synchronization workflow and record every edit
 - Report honestly — a low-confidence score is valuable information
 - Flag areas where you lack sufficient context to validate
 
@@ -94,6 +108,8 @@ Scope: <documents validated>
 - [ ] Each finding has an evidence path or explicit "no evidence found"
 - [ ] Summary table has accurate counts
 - [ ] Stale documentation risks are identified
+- [ ] Cross-document contradictions are listed or explicitly absent
+- [ ] Auto-heal actions are recorded when synchronization mode is active
 - [ ] Recommended actions are actionable
 
 ## Cross-References

package/templates/canonical/skills/llm-prompt-injection-guard/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: llm-prompt-injection-guard
+description: Detects user-input-to-LLM prompt injection paths, unsafe RAG ingestion, unvalidated LLM outputs, and poisoned AI memory/documentation flows.
+version: 1.0.0
+---
+
+# LLM Prompt Injection Guard
+
+Use this skill for AI-augmented applications, RAG pipelines, agent tools, prompt builders, chat handlers, knowledge ingestion, or any code that sends user-controlled data to an LLM.
+
+## Procedure
+
+1. Detect LLM calls, prompt templates, tool outputs, embedding pipelines, document ingestion, and agent memory writes.
+2. Trace user-controlled sources into prompts, system messages, tool descriptions, retrieval documents, logs, knowledge-base files, and memory files.
+3. Flag missing controls:
+   - no prompt boundary separation
+   - no input sanitization or quoting
+   - no output schema validation
+   - tool results trusted without validation
+   - externally sourced content written into durable memory without provenance
+   - secrets or policies exposed to user-influenced context
+4. Require adversarial tests for high-risk LLM paths.
+
+## Output
+
+Write `.engineering-intelligence/reports/LLM-PROMPT-INJECTION-<slug>.md`:
+
+```markdown
+# LLM Prompt Injection Review: <summary>
+
+## Data Paths
+| Source | LLM / Memory Sink | Control Present | Risk | Evidence |
+|---|---|---|---|---|
+
+## Findings
+- <prompt injection or output validation risk>
+
+## Required Tests
+- <adversarial test cases>
+```
+
+## Quality Gates
+
+- [ ] LLM calls and memory/document ingestion paths were inventoried
+- [ ] User-controlled sources were traced to LLM and durable-memory sinks
+- [ ] Output validation was checked
+- [ ] High-risk paths have adversarial tests or blocking findings

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

@@ -22,6 +22,11 @@ Maintain durable, long-lived engineering memory. Memory is for decisions and pat
 | `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 |
+| `regression-patterns.md` | Recurring bug categories and proven regression test templates | Bugfixes that reveal reusable failure patterns |
+
+## Regression Pattern Ownership
+
+Testing Intelligence Engine owns detection and proposal of regression patterns during bugfix validation. Memory Sync owns durable persistence to `.engineering-intelligence/memory/regression-patterns.md` after confirming the pattern is reusable and evidence-backed. Testing Intelligence must not directly persist durable memory unless it is explicitly running through Memory Sync.
 
 ## Staleness Detection Rules
 
@@ -58,12 +63,25 @@ A memory entry may be stale if:
    - Is this a decision or just an implementation detail?
    - Is this captured better elsewhere (knowledge-base, context)?
 
+5. **Memory Pruning Audit** — During initialization, major refactors, or explicit sync:
+   - Flag entries where referenced code no longer exists
+   - Flag entries superseded for more than six months
+   - Flag patterns contradicted by current `convention-detector` output
+   - Flag decisions that conflict with accepted ADRs
+   - Propose retirement with evidence; do not delete historical decisions silently
+
+6. **Regression Pattern Update** — For bugfixes:
+   - Classify the bug category (pagination boundary, null/empty collection, race condition, permission bypass, retry/idempotency, schema drift, API contract mismatch, etc.)
+   - Match against `.engineering-intelligence/memory/regression-patterns.md`
+   - Add or update a reusable regression test template when the pattern is durable
+
 ## 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
+- **Pruning with evidence**: Retire or deprecate stale memory only with evidence and status updates
 - **No product code**: Memory synchronization never modifies product code
 
 ## Quality Gates
@@ -73,6 +91,8 @@ A memory entry may be stale if:
 - [ ] New entries are truly durable (not transient implementation details)
 - [ ] All entries have evidence citations
 - [ ] Superseded entries are marked, not deleted
+- [ ] Memory pruning audit was run for initialization and major refactors
+- [ ] Regression patterns were checked for bugfixes
 
 ## Cross-References
 

package/templates/canonical/skills/operations-readiness-engine/SKILL.md

@@ -8,13 +8,16 @@ version: 1.0.0
 
 Use this skill when a change affects deployment, infrastructure, runtime behavior, SLOs, data migrations, incident response, or production monitoring.
 
+For medium-and-above risk changes, use the rollback planning section even when the change is not deployment-bound. Rollback planning is a release safety gate, not only an infrastructure concern.
+
 ## Procedure
 
 1. Identify deployment target, environment variables, infrastructure files, CI/CD gates, and runtime services.
 2. Define release strategy: normal deploy, canary, blue/green, feature flag, or manual rollout.
 3. Define rollback plan and data recovery constraints.
 4. Define observability: metrics, traces, logs, dashboards, alerts, and ownership.
-5. Confirm production readiness with objective gates.
+5. Inject or flag observability gaps for new functions, endpoints, jobs, service interactions, and business events.
+6. Confirm production readiness with objective gates.
 
 ## Outputs
 
@@ -34,16 +37,24 @@ Write `.engineering-intelligence/aidlc/operations/operations-readiness.md`:
 | Signal | Source | Threshold | Owner | Runbook |
 |---|---|---|---|---|
 
+## Observability Injection
+| New / Changed Path | Entry Log | Exit Log | Trace Span | Error Metric | Business Event | Status |
+|---|---|---|---|---|---|---|
+
 ## Rollback
-- Code rollback:
-- Data rollback:
-- Configuration rollback:
+- Code rollback: `git revert <commit>` or <branch rollback sequence>
+- Data rollback: <down migration / compensating SQL / irreversible approval>
+- Feature flag rollback: <toggle and expected effect>
+- Infrastructure rollback: <IaC rollback sequence>
+- External dependency rollback: <vendor/config rollback>
 
 ## Readiness Gates
 - [ ] Build passes
 - [ ] Tests pass
 - [ ] Migrations are backward compatible or downtime is approved
 - [ ] Alerts/runbooks exist for changed failure modes
+- [ ] Rollback planner covers code, data, feature flag, and infrastructure rollback for medium+ risk
+- [ ] New endpoints/functions/services have logging, tracing, metrics, and business-event coverage or explicit gaps
 - [ ] Secrets and environment variables are documented securely
 ```
 
@@ -52,3 +63,5 @@ Write `.engineering-intelligence/aidlc/operations/operations-readiness.md`:
 - Never execute production deployment without explicit user approval.
 - Mark unknown production constraints in `open-questions.md`.
 - For database changes, require backward-compatible migration planning unless downtime is approved.
+- Medium-and-above risk changes require rollback procedures in both `operations-readiness.md` and the CHG record.
+- Irreversible steps require explicit human approval.

package/templates/canonical/skills/requirement-scoper/SKILL.md

@@ -21,6 +21,13 @@ Act as a detailed Business Analyst and Technical Architect persona. Analyze the
    - Identify domain logic in `knowledge-base/` matching the request category
    - Query dependency/service graphs to locate related modules and boundaries
    - Read architecture memory to understand tech constraints and guidelines
+   - Scan relevant modules for implicit invariants and dominant implementation constraints before asking questions:
+     - retry strategies, timeout values, rate limits, pagination defaults
+     - locking/idempotency patterns
+     - validation style and error codes
+     - logging/tracing conventions
+     - framework patterns used in 80% or more of similar code
+   - Surface confirmed dominant patterns as constraints in the requirements document.
 
 2. **Formulate Scoping Questions** — Identify gaps, ambiguities, and edge cases. Ask the user 3 to 5 targeted questions covering:
    - **Business Value & Scope**: What are the limits of the MVP?
@@ -47,6 +54,7 @@ The final requirements document `knowledge-base/19-requirements.md` must follow
 - **Logic & Configuration**: <Exact details on implementation strategy, libraries, config parameters>
 - **System Boundaries & Dependencies**: <Files/modules affected based on graph mappings>
 - **Edge Cases & Failure Modes**: <Exactly how to handle failures, retries, limits>
+- **Implicit Codebase Constraints**: <Dominant existing patterns discovered from relevant modules, with evidence paths>
 
 ## 3. Agile Delivery Model
 - **Epic**: <epic or initiative>
@@ -81,5 +89,6 @@ Provide the exact prompt to pass to the coding agent to execute this change:
 - [ ] Clear business goals and technical boundaries defined.
 - [ ] At least 3 scoping questions asked and logged.
 - [ ] User story, acceptance criteria, priority, dependencies, and Ready/Done gates are documented.
+- [ ] Implicit codebase constraints were mined and cited before questions were finalized.
 - [ ] Finalized prompt maps exact files and modules.
 - [ ] Output does not contain any code modification.