engineering-intelligence 1.2.0 → 1.4.0

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/memory-sync-engine/SKILL.md

@@ -22,6 +22,7 @@ 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 |
 
 ## Staleness Detection Rules
 
@@ -58,12 +59,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 +87,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

@@ -14,7 +14,8 @@ Use this skill when a change affects deployment, infrastructure, runtime behavio
 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 +35,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 +61,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.

package/templates/canonical/skills/security-audit-engine/SKILL.md

@@ -32,8 +32,13 @@ Identify security risks through systematic, evidence-backed analysis of dependen
    - Check version against known CVE databases (cite CVE IDs)
    - Flag dependencies with no updates in >12 months (abandonment risk)
    - Identify transitive dependencies with known vulnerabilities
+   - Check license compatibility against the project license
+   - Check maintenance health (days since last release/commit when available)
+   - For frontend packages, estimate bundle size impact or require a bundle-size check
    - Note severity: critical, high, medium, low
 
+   Trigger this targeted dependency risk review whenever manifests add a new package. Critical CVEs block completion before commit. Unknown license or maintenance data must be recorded as risk, not ignored.
+
 2. **Auth/Authz Pattern Review** — Analyze authentication and authorization:
 
    | Check | What to Look For |
@@ -104,9 +109,9 @@ Write `knowledge-base/20-security-assessment.md`:
 - Overall risk: low | medium | high | critical
 
 ## Dependency Vulnerabilities
-| Dependency | Version | CVE | Severity | Fix Available |
-|---|---|---|---|---|
-| lodash | 4.17.15 | CVE-2020-8203 | High | Yes (4.17.21) |
+| Dependency | Version | CVE | Severity | Fix Available | License | Maintenance | Bundle Impact |
+|---|---|---|---|---|---|---|---|
+| lodash | 4.17.15 | CVE-2020-8203 | High | Yes (4.17.21) | MIT | maintained | n/a |
 
 ## Auth/Authz Assessment
 - Mechanism: <description>
@@ -149,6 +154,8 @@ Write `knowledge-base/20-security-assessment.md`:
 ## Quality Gates
 
 - [ ] All dependency vulnerabilities cite CVE IDs and affected versions
+- [ ] New package additions include CVE, license, maintenance, and bundle-size risk where applicable
+- [ ] Critical CVEs block completion
 - [ ] Auth/authz review covers both authentication and authorization
 - [ ] Secrets scan does not expose actual secret values in the report
 - [ ] OWASP Top 10 items each have a status with evidence or rationale

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

@@ -96,6 +96,15 @@ This capability does not modify product code.
    - If no freshness comment exists, add it after the document title (first `#` heading)
    - Never modify document content — only metadata comments
 
+   Also add section-level confidence metadata to each H2 section when evidence can be resolved:
+
+   ```markdown
+   ## Authentication Flow
+   <!-- section-confidence: level=high, score=91, verified_at=2026-06-04T10:00:00Z, evidence=src/auth/middleware.ts -->
+   ```
+
+   Agents must prefer high/medium confidence sections and skip low-confidence sections unless they verify the section against source first.
+
 6. **Determine sync actions** — Based on freshness scores, determine required actions:
 
    | Condition | Action |
@@ -161,6 +170,14 @@ This capability does not modify product code.
    - The list of changed source files
    - The staleness reason (file modified, file deleted, file moved, age)
 
+9. **Pre-Implementation Drift Trigger** — When invoked by `engineering-intelligence-skill`, return a blocking drift decision:
+
+   | Condition | Decision |
+   |---|---|
+   | All scoped artifacts >= 60 | Proceed |
+   | Any scoped artifact 50-59 | Sync before implementation or mark stale risk in impact report |
+   | Any scoped artifact < 50 | Block implementation until incremental sync or explicit user risk acceptance |
+
 ## Quality Gates
 
 - [ ] All knowledge base, memory, and context documents are inventoried
@@ -169,10 +186,12 @@ This capability does not modify product code.
 - [ ] Freshness scores follow the defined calculation formula
 - [ ] Score interpretation matches the defined status table
 - [ ] Freshness metadata is injected without modifying document content
+- [ ] Section-level confidence metadata is added for H2 sections where evidence can be resolved
 - [ ] FRESHNESS-report.md exists at `.engineering-intelligence/reports/FRESHNESS-report.md`
 - [ ] Structural changes (deleted/moved files) are detected and reported
 - [ ] Documents below threshold are queued for incremental sync
 - [ ] Module-level aggregation is included in the report
+- [ ] Pre-implementation drift decision is returned when scoped to a planned change
 
 ## Cross-References
 

package/templates/canonical/skills/testing-intelligence-engine/SKILL.md

@@ -13,6 +13,8 @@ Determine the minimum sufficient test coverage for a change based on risk assess
 - Impact report (`.engineering-intelligence/reports/IMP-XXX-*.md`)
 - Existing test patterns in the repository
 - Change classification (feature, bugfix, refactor, etc.)
+- Coverage reports when available (`coverage-final.json`, `coverage.xml`, `lcov.info`, `go test -cover`, pytest coverage output)
+- Agile acceptance criteria from `.engineering-intelligence/aidlc/agile/acceptance-criteria.md`
 
 ## Risk-Based Test Selection Matrix
 
@@ -29,11 +31,18 @@ Determine the minimum sufficient test coverage for a change based on risk assess
    - Identify test framework(s) in use (Jest, Mocha, pytest, Go testing, etc.)
    - Locate test directories and naming patterns
    - Map tests to source files (by convention or configuration)
-   - Identify untested critical paths
+   - Parse real coverage reports where available:
+     - Jest/Vitest/Istanbul JSON (`coverage-final.json`)
+     - LCOV (`lcov.info`)
+     - pytest `coverage.xml`
+     - Go `go test -cover` output
+   - Map uncovered lines to modules and critical paths
 
 2. **Map Change to Tests** — Using the impact report:
    - List source files/functions changed
    - Find existing tests covering those files
+   - Build a source-line to test-file map from coverage where possible
+   - Run or recommend targeted impacted tests first, then broader validation
    - Identify tests that should exist but don't (coverage gaps)
 
 3. **Determine Required Tests** — Using the risk matrix above:
@@ -56,6 +65,15 @@ Determine the minimum sufficient test coverage for a change based on risk assess
    - Negative-path and permission tests for security changes
    - Data migration and rollback tests for schema changes
 
+   **For API/service integration changes**:
+   - Generate integration test stubs from `knowledge-base/04-api-documentation.md` and `service-graph.json`
+   - Cover happy path, auth failure, downstream timeout, and validation error
+   - Match existing test framework, describe/it nesting, mock setup, assertion library, and factory style
+
+   **For complex validators or combinatorial logic**:
+   - Recommend property-based tests (`fast-check`, `hypothesis`, `proptest`, or project equivalent)
+   - Include seed examples and rationale
+
 4. **Identify Coverage Gaps** — Report:
    - Critical paths with no test coverage
    - Changed behavior with no corresponding test
@@ -66,6 +84,10 @@ Determine the minimum sufficient test coverage for a change based on risk assess
    - Test cases to write (describe what, not write the test code)
    - Validation commands to run
 
+6. **Verify Acceptance Criteria** — Produce an Acceptance Criteria Verification Matrix mapping every criterion to automated tests, manual verification, or an unavailable check. Missing mappings block Definition of Done.
+
+7. **Record Regression Patterns** — For bugfixes, compare against `.engineering-intelligence/memory/regression-patterns.md`. Reuse matching templates or add a new durable pattern when a bug category is likely to recur.
+
 ## Output
 
 ### Per-Change Testing (in `.changes/CHG-XXX-*.md`)
@@ -99,6 +121,14 @@ Only update when documenting project-wide testing posture:
 ## Coverage Gaps
 - <critical untested areas>
 
+## Evidence-Based Coverage
+| Source File | Changed Lines | Covering Tests | Uncovered Lines |
+|---|---|---|---|
+
+## Acceptance Criteria Verification Matrix
+| Criterion | Covering Test / Manual Check | Result |
+|---|---|---|
+
 ## Running Tests
 - All tests: `<command>`
 - Specific suite: `<command>`
@@ -110,6 +140,9 @@ Only update when documenting project-wide testing posture:
 - Recommend tests proportional to risk — don't mandate full-suite runs for low-risk changes
 - Always note when validation was not actually run (only recommended)
 - Never claim test coverage without checking existing tests
+- Prefer real coverage reports over proximity estimates when reports exist
+- Target impacted tests first, then run broader suites according to risk
+- Missing acceptance-criteria mappings block Definition of Done
 - Record test results honestly, including failures
 
 ## Quality Gates
@@ -117,7 +150,10 @@ Only update when documenting project-wide testing posture:
 - [ ] Impact report was consulted for risk level
 - [ ] Test recommendations match the risk level
 - [ ] Existing test coverage was checked before recommending new tests
+- [ ] Coverage reports were parsed when available
+- [ ] Impacted tests were identified separately from full-suite validation
 - [ ] Coverage gaps in critical paths are flagged
+- [ ] Acceptance criteria are mapped to validation evidence
 
 ## Cross-References
 

package/templates/canonical/skills/type-safety-engine/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: type-safety-engine
+description: Validates generated code against the project type system, traces type-level dependencies, and loops on compiler errors until clean or blocked.
+version: 1.0.0
+---
+
+# Type Safety Engine
+
+Use this skill for TypeScript, Python, Go, Rust, Java, Kotlin, C#, or any project with a declared type checker. It is a blocking gate for generated code in typed projects.
+
+## Inputs
+
+- Changed files from the impact report or current diff
+- Project manifests and type-check configuration
+- Existing graph artifacts under `.engineering-intelligence/graph/`
+
+## Procedure
+
+1. **Detect Type System**
+   - TypeScript: `tsconfig.json`, `package.json`, `tsc`
+   - Python: `mypy.ini`, `pyproject.toml`, `pyrightconfig.json`, annotations
+   - Go: `go.mod`
+   - Rust: `Cargo.toml`
+   - Java/Kotlin/C#: project build files
+
+2. **Trace Type Dependencies**
+   - TypeScript: run or recommend `tsc --listFilesOnly` and use the TypeScript compiler API when available to identify interface, type alias, enum, generic, declaration, and ambient type dependencies.
+   - Python: run or recommend `mypy --show-column-numbers` or `pyright` and trace annotation/import relationships.
+   - Add high-confidence `imports-type` edges to `.engineering-intelligence/graph/dependency-graph.json` for type-only dependencies, with evidence paths.
+
+3. **Run Type Check**
+   - Use the project’s existing command first (`npm run typecheck`, `pnpm typecheck`, `mypy`, `pyright`, `go test`, `cargo check`, etc.).
+   - If no command exists, use the safest detected command and record that it was inferred.
+
+4. **Map Errors**
+   Write a Type Error Map in the active unit build/test summary:
+
+   ```markdown
+   ## Type Error Map
+   | File | Line | Column | Symbol | Error | Proposed Fix | Status |
+   |---|---:|---:|---|---|---|---|
+   ```
+
+5. **Fix Loop**
+   - Fix targeted type errors only.
+   - Rerun the relevant type check.
+   - Continue until clean or a blocker is recorded.
+
+## Output
+
+Write or update `.engineering-intelligence/aidlc/construction/<unit>/build-and-test/type-safety-summary.md`:
+
+```markdown
+# Type Safety Summary: <unit>
+
+## Commands
+- `<command>`: <passed|failed|unavailable>
+
+## Type Dependency Edges
+- `imports-type`: <from> -> <to> (evidence: <path>)
+
+## Type Error Map
+<table>
+
+## Result
+<clean|blocked|not applicable>
+```
+
+## Rules
+
+- Never mark typed code complete while type errors remain unaddressed.
+- If a type checker is unavailable, record `not applicable` with evidence rather than silently skipping.
+- Type-only dependencies must be included in impact analysis for typed languages.
+
+## Quality Gates
+
+- [ ] Type checker command was detected or explicitly unavailable
+- [ ] Type-level dependencies were traced for shared types/interfaces
+- [ ] `imports-type` graph edges were added or confirmed unnecessary
+- [ ] Type Error Map exists for failures
+- [ ] Final type status is clean, blocked with evidence, or not applicable

package/templates/canonical/workflows/engineering-intelligence.md

@@ -14,10 +14,11 @@ Use the `engineering-intelligence-skill` capability for the user's accompanying
 4. **Plan Agile + AI-DLC Work** — Update backlog, acceptance criteria, Definition of Ready, `.engineering-intelligence/aidlc/execution-plan.md`, and `aidlc-state.md`
 5. **Implement** — Make the requested code changes following established patterns
 6. **Test** — Add/update tests proportional to risk; execute and record results
-7. **Validate** — Run available linters, type checks, test suites, scans, and architecture checks as environmental backpressure
-8. **Sync Intelligence** — Incrementally update only affected knowledge, memory, context, event, graph artifacts, and AI-DLC artifacts
-9. **Record Change** — Write `.changes/CHG-XXX-<summary>.md` referencing related reports
-10. **Review Gate** — For high-risk changes, run engineering-change review before completion
+7. **Safety Gates** — Run freshness, type safety, API compatibility, migration safety, convention, acceptance-mapping, dependency-risk, and rollback gates when applicable
+8. **Validate** — Run available linters, type checks, test suites, scans, and architecture checks as environmental backpressure
+9. **Sync Intelligence** — Incrementally update only affected knowledge, memory, context, event, graph artifacts, and AI-DLC artifacts
+10. **Record Change** — Write `.changes/CHG-XXX-<summary>.md` referencing related reports and acceptance verification
+11. **Review Gate** — For high-risk changes, run engineering-change review before completion
 
 ## Completion Report
 
@@ -28,5 +29,6 @@ Finish with:
 - Synchronized intelligence artifacts
 - Related reports (IMP-XXX, REV-XXX)
 - Agile artifacts updated (backlog, stories, acceptance criteria, Definition of Done)
+- Safety gates run (freshness, type, API, migration, acceptance mapping)
 - Unresolved risks or follow-ups
 - AI-DLC breadcrumb (`AI-DLC: <phase> -> <stage> -> <status>`)

package/templates/canonical/workflows/initialize-engineering-intelligence.md

@@ -30,8 +30,9 @@ Analyzes this repository thoroughly without changing product code. Produces a co
 4. **Generate Memory** — Extract durable decisions and patterns
 5. **Generate Context** — Create concise AI navigation maps
 6. **Build Graphs** — Generate evidence-backed architecture graphs
-7. **Initialize AI-DLC + Agile** — Create `aidlc-state.md`, `audit.md`, `open-questions.md`, `execution-plan.md`, Agile delivery artifacts, and `construction/cross-unit-discoveries.md`
-8. **Record** — Write initialization change record
+7. **Initialize AI-DLC + Agile** — Create `aidlc-state.md`, `audit.md`, `open-questions.md`, `execution-plan.md`, `checkpoints.md`, Agile delivery artifacts, and `construction/cross-unit-discoveries.md`
+8. **Audit Memory** — Run memory pruning audit and initialize `.engineering-intelligence/memory/regression-patterns.md`
+9. **Record** — Write initialization change record
 
 ## Important