engineering-intelligence 0.8.1 → 1.1.0

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

@@ -0,0 +1,165 @@
+---
+name: security-audit-engine
+description: Performs evidence-based security audits covering dependency vulnerabilities, auth/authz patterns, secrets detection, OWASP Top 10 compliance, and input validation. Use during initialization, before releases, or when security-sensitive changes are detected.
+version: 3.0.0
+---
+
+# Security Audit Engine
+
+Identify security risks through systematic, evidence-backed analysis of dependencies, authentication patterns, secrets hygiene, and input handling.
+
+## Inputs
+
+- Repository root path
+- Mode: `full` (comprehensive audit) or `targeted` (specific area or post-change)
+- Optional: scope constraints (specific modules, change diff)
+- Optional: previous assessment (`knowledge-base/20-security-assessment.md`) for delta comparison
+
+## Procedure
+
+1. **Dependency Vulnerability Scanning** — Parse lock files and manifests:
+
+   | File | Ecosystem |
+   |---|---|
+   | `package-lock.json` / `yarn.lock` / `pnpm-lock.yaml` | npm |
+   | `Pipfile.lock` / `requirements.txt` | Python |
+   | `Cargo.lock` | Rust |
+   | `go.sum` | Go |
+   | `Gemfile.lock` | Ruby |
+   | `composer.lock` | PHP |
+
+   For each dependency:
+   - 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
+   - Note severity: critical, high, medium, low
+
+2. **Auth/Authz Pattern Review** — Analyze authentication and authorization:
+
+   | Check | What to Look For |
+   |---|---|
+   | Auth mechanism | JWT, session, OAuth, API keys — identify which is used |
+   | Token handling | Storage (cookies, localStorage), expiration, refresh flow |
+   | Password handling | Hashing algorithm, salt usage, strength validation |
+   | Permission model | RBAC, ABAC, ACL — identify and assess |
+   | Route protection | Unprotected endpoints that should require auth |
+   | Privilege escalation | Missing authorization checks on sensitive operations |
+   | Session management | Fixation prevention, timeout, invalidation |
+
+3. **Secrets Detection** — Scan for exposed credentials:
+
+   | Pattern | Risk |
+   |---|---|
+   | Hardcoded API keys / tokens | Critical |
+   | Database connection strings with passwords | Critical |
+   | Private keys committed to repository | Critical |
+   | `.env` files without `.gitignore` coverage | High |
+   | Secrets in CI/CD configuration | High |
+   | Default/test credentials in non-test code | Medium |
+   | Comments containing sensitive URLs or tokens | Medium |
+
+   Check `.gitignore` for adequate secret file exclusions.
+
+4. **OWASP Top 10 Checklist** — Assess against current OWASP Top 10:
+
+   | # | Category | Assessment |
+   |---|---|---|
+   | A01 | Broken Access Control | Check route guards, CORS, directory traversal |
+   | A02 | Cryptographic Failures | Check TLS, hashing, encryption at rest |
+   | A03 | Injection | Check SQL, NoSQL, OS command, LDAP injection |
+   | A04 | Insecure Design | Check business logic flaws, missing rate limits |
+   | A05 | Security Misconfiguration | Check default configs, verbose errors, headers |
+   | A06 | Vulnerable Components | Cross-ref with dependency scan results |
+   | A07 | Auth Failures | Cross-ref with auth/authz review |
+   | A08 | Data Integrity Failures | Check deserialization, CI/CD pipeline integrity |
+   | A09 | Logging Failures | Check audit logging, sensitive data in logs |
+   | A10 | SSRF | Check URL handling, outbound request validation |
+
+   Rate each as: `pass`, `concern`, `fail`, or `not-applicable`.
+
+5. **Input Validation Pattern Review** — Assess input handling:
+
+   | Check | Description |
+   |---|---|
+   | Schema validation | Are API inputs validated against schemas? |
+   | Sanitization | Is user input sanitized before use? |
+   | File upload | Are uploads validated (type, size, content)? |
+   | Query parameters | Are query params validated and typed? |
+   | Output encoding | Is output encoded to prevent XSS? |
+   | Rate limiting | Are endpoints rate-limited? |
+
+6. **Generate Assessment** — Write findings to `knowledge-base/20-security-assessment.md`.
+
+## Output Format
+
+Write `knowledge-base/20-security-assessment.md`:
+
+```markdown
+# Security Assessment
+
+## Meta
+- Generated: <ISO timestamp>
+- Mode: full | targeted
+- Scope: <what was examined>
+- 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) |
+
+## Auth/Authz Assessment
+- Mechanism: <description>
+- Findings: <issues found>
+- Risk: <level>
+
+## Secrets Scan
+| Finding | File | Risk | Remediation |
+|---|---|---|---|
+| Hardcoded API key | src/config.ts:42 | Critical | Move to env variable |
+
+## OWASP Top 10
+| # | Category | Status | Evidence |
+|---|---|---|---|
+| A01 | Broken Access Control | concern | <finding> |
+
+## Input Validation
+| Area | Status | Evidence |
+|---|---|---|
+| API schema validation | pass | Uses Zod on all endpoints |
+
+## Recommendations
+1. <prioritized remediation actions>
+
+## Evidence
+- <file path citations for all findings>
+
+---
+*This security assessment did not modify product code.*
+```
+
+## Rules
+
+- Never assume a vulnerability exists without evidence — cite file paths and line numbers
+- Flag severity honestly — do not inflate or suppress findings
+- Secrets detection must not log or expose the actual secret values in reports
+- Mark `not-applicable` for OWASP categories genuinely irrelevant to the project
+- This capability is analytical only — it must not modify product code
+
+## Quality Gates
+
+- [ ] All dependency vulnerabilities cite CVE IDs and affected versions
+- [ ] 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
+- [ ] Input validation assessment covers API boundaries
+- [ ] Recommendations are prioritized by severity
+- [ ] Report ends with the "did not modify product code" statement
+
+## Cross-References
+
+- Depends on: `deep-project-knowledge-extractor` (project structure understanding)
+- Used by: `engineering-intelligence-skill`, `impact-analysis-engine` (security risk scoring)
+- Updates: `knowledge-base/20-security-assessment.md`
+
+This capability is analytical only. It must not modify product code.

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

@@ -0,0 +1,185 @@
+---
+name: staleness-detector
+description: Compares knowledge-base document timestamps against related source file modification times, scores each document 0-100 for freshness, triggers incremental sync when freshness drops below threshold, and adds freshness metadata to document headers.
+version: 3.0.0
+---
+
+# Staleness Detector
+
+Monitor the freshness of all engineering intelligence documents by comparing their last-updated timestamps against the modification times of the source files they describe. Produce a freshness report and trigger incremental sync for stale documents.
+
+This capability does not modify product code.
+
+## Inputs
+
+- Repository root path
+- Knowledge base directory (`knowledge-base/`)
+- Memory directory (`.engineering-intelligence/memory/`)
+- Context directory (`.engineering-intelligence/context/`)
+- Optional: specific document or module to check
+- Optional: custom freshness threshold (default: 60)
+
+## Procedure
+
+1. **Inventory knowledge documents** — Enumerate all documents in:
+   - `knowledge-base/*.md` (00 through 16)
+   - `.engineering-intelligence/memory/*.md`
+   - `.engineering-intelligence/context/*.md`
+   - `.engineering-intelligence/graph/*.json`
+
+   For each document, extract:
+   - Document path
+   - Last modified timestamp (from filesystem or frontmatter `last_updated` field)
+   - Evidence citations within the document (file paths referenced)
+
+2. **Extract evidence dependencies** — For each knowledge document, parse all evidence citations to build a dependency map:
+
+   ```markdown
+   ## Document Dependencies
+
+   | Document | Depends On (Source Files) |
+   |---|---|
+   | `02-architecture.md` | `src/app/`, `src/server/`, `next.config.mjs` |
+   | `05-database.md` | `prisma/schema.prisma`, `src/db/`, `migrations/` |
+   | `06-authentication.md` | `src/auth/`, `auth.config.ts`, `middleware.ts` |
+   ```
+
+3. **Check source file modification times** — For each source file referenced by a knowledge document:
+   - Get the file's last modification time via `git log -1 --format=%cI -- <path>` (preferred) or filesystem mtime
+   - Compare against the knowledge document's last-updated timestamp
+   - Track files that no longer exist (deleted or moved)
+
+4. **Calculate freshness score** — Score each document 0–100 using this formula:
+
+   ```
+   base_score = 100
+
+   For each referenced source file:
+     days_since_doc_update = (now - document_last_updated).days
+     days_since_file_change = (now - file_last_modified).days
+
+     if file was modified AFTER document was last updated:
+       staleness_penalty = min(30, (file_modified - doc_updated).days * 3)
+       base_score -= staleness_penalty
+
+     if file no longer exists:
+       base_score -= 25  (major structural change)
+
+     if file was renamed/moved (detected via git):
+       base_score -= 15  (references are broken)
+
+   age_penalty = min(20, days_since_doc_update * 0.5)
+   base_score -= age_penalty
+
+   freshness_score = max(0, base_score)
+   ```
+
+   **Score interpretation:**
+
+   | Score | Status | Meaning |
+   |---|---|---|
+   | 80–100 | 🟢 Fresh | Document is current and reliable |
+   | 60–79 | 🟡 Aging | Document may have minor inaccuracies |
+   | 40–59 | 🟠 Stale | Document likely has outdated information |
+   | 20–39 | 🔴 Very Stale | Document is unreliable, needs re-generation |
+   | 0–19 | ⛔ Obsolete | Document may be misleading, urgent refresh needed |
+
+5. **Add freshness metadata** — Inject or update a frontmatter block at the top of each knowledge document:
+
+   ```markdown
+   <!-- freshness: score=75, status=aging, last_checked=2024-01-20T14:30:00Z -->
+   <!-- stale_sources: src/auth/middleware.ts (modified 5 days after doc update) -->
+   ```
+
+   Rules for metadata injection:
+   - If a `<!-- freshness: -->` comment already exists, update it in place
+   - If no freshness comment exists, add it after the document title (first `#` heading)
+   - Never modify document content — only metadata comments
+
+6. **Determine sync actions** — Based on freshness scores, determine required actions:
+
+   | Condition | Action |
+   |---|---|
+   | Score < threshold (default 60) | Queue for incremental sync via `incremental-sync-engine` |
+   | Score < 30 | Flag as critical in report, recommend full re-generation |
+   | Referenced file deleted | Flag structural change, recommend manual review |
+   | Referenced file moved | Update evidence citations, re-verify claims |
+   | Multiple documents stale for same module | Recommend module-level re-discovery |
+
+7. **Generate FRESHNESS-report.md** — Write to `.engineering-intelligence/reports/FRESHNESS-report.md`:
+
+   ```markdown
+   # Freshness Report
+
+   Generated: <timestamp>
+   Threshold: <score>
+   Documents scanned: <N>
+
+   ## Summary
+
+   | Status | Count | Percentage |
+   |---|---|---|
+   | 🟢 Fresh (80-100) | <N> | <N%> |
+   | 🟡 Aging (60-79) | <N> | <N%> |
+   | 🟠 Stale (40-59) | <N> | <N%> |
+   | 🔴 Very Stale (20-39) | <N> | <N%> |
+   | ⛔ Obsolete (0-19) | <N> | <N%> |
+
+   ## Document Scores
+
+   | Document | Score | Status | Stale Sources | Last Updated | Action Needed |
+   |---|---|---|---|---|---|
+   | `02-architecture.md` | 45 | 🟠 Stale | `src/app/layout.tsx` (+3d) | 2024-01-10 | Incremental sync |
+   | `05-database.md` | 90 | 🟢 Fresh | — | 2024-01-18 | None |
+   | ... | ... | ... | ... | ... | ... |
+
+   ## Structural Changes
+
+   | Type | File | Affected Documents |
+   |---|---|---|
+   | Deleted | `src/old-auth/handler.ts` | `06-authentication.md` |
+   | Moved | `src/utils.ts` → `src/lib/utils.ts` | `01-repository-structure.md` |
+
+   ## Recommended Actions
+
+   1. **Critical** — Re-generate: <list of documents with score < 30>
+   2. **High** — Incremental sync: <list of documents with score < 60>
+   3. **Medium** — Review: <list of documents with score 60-79>
+   4. **Structural** — Manual review needed: <list of deleted/moved file impacts>
+
+   ## Module-Level Freshness
+
+   | Module | Avg Document Score | Documents Below Threshold |
+   |---|---|---|
+   | auth | 42 | `06-authentication.md`, `context/critical-paths.md` |
+   | api | 88 | — |
+   | ... | ... | ... |
+   ```
+
+8. **Trigger incremental sync** — For documents below the threshold, invoke `incremental-sync-engine` with:
+   - The specific document to update
+   - The list of changed source files
+   - The staleness reason (file modified, file deleted, file moved, age)
+
+## Quality Gates
+
+- [ ] All knowledge base, memory, and context documents are inventoried
+- [ ] Evidence citations are parsed from every document
+- [ ] Source file modification times are checked against document timestamps
+- [ ] Freshness scores follow the defined calculation formula
+- [ ] Score interpretation matches the defined status table
+- [ ] Freshness metadata is injected without modifying document content
+- [ ] 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
+
+## Cross-References
+
+- Used by: `ongoing-learning-engine` (for freshness monitoring)
+- Uses: `incremental-sync-engine` (to refresh stale documents)
+- Consumed by: `engineering-intelligence-skill`, `engineering-orchestrator`
+- Feeds into: `.engineering-intelligence/reports/FRESHNESS-report.md`
+- Related: `knowledge-base-validator` (validates content accuracy; staleness-detector validates currency)
+
+This capability does not modify product code.

package/templates/canonical/workflows/create-project.md

@@ -0,0 +1,63 @@
+---
+description: Create a new project from scratch with full AIDLC — from architectural interview through scaffolding, intelligence initialization, and convention detection.
+---
+
+# Create Project
+
+Chain `greenfield-architect` → scaffold → `initialize-intelligence-skill` → `convention-detector` to produce a fully instrumented project with engineering intelligence from day one.
+
+## Input
+
+A description of the project to create: purpose, domain, technology preferences, and constraints. If insufficient context is provided, the architectural interview in step 1 will gather it.
+
+## Output
+
+A complete, scaffolded project with:
+
+| Category | Content |
+|---|---|
+| Project scaffold | Directory structure, configuration, dependencies, build system |
+| Knowledge Base | `knowledge-base/` — initialized project intelligence |
+| Memory | `.engineering-intelligence/memory/` — initial decisions and patterns |
+| Context | `.engineering-intelligence/context/` — AI navigation maps |
+| Graphs | `.engineering-intelligence/graph/` — initial architecture graphs |
+| Conventions | `knowledge-base/06-conventions-and-standards.md` — detected and configured conventions |
+| Change Record | `.changes/CHG-000-initialization.md` — project creation record |
+
+## Execution Steps
+
+1. **Architectural Interview** — Invoke `greenfield-architect` to conduct a structured interview:
+   - Gather requirements: domain, scale, team size, deployment targets
+   - Explore technology choices: language, framework, database, infrastructure
+   - Define architecture: monolith vs microservices, API style, data patterns
+   - Record decisions as ADRs in `knowledge-base/05-architecture-decisions.md`
+   - Produce a project blueprint before proceeding
+
+2. **Scaffold Project** — Based on the architectural blueprint:
+   - Create directory structure following chosen conventions
+   - Initialize package manifests and dependency management
+   - Configure build system, linting, and formatting
+   - Set up test infrastructure
+   - Create initial CI/CD pipeline configuration
+   - Add README, LICENSE, and contributing guidelines
+   - Initialize git repository with initial commit
+
+3. **Initialize Intelligence** — Invoke `initialize-intelligence-skill`:
+   - Generate knowledge-base documents from the scaffolded project
+   - Build initial architecture graphs
+   - Create AI context and navigation maps
+   - Write initialization change record (CHG-000)
+
+4. **Detect Conventions** — Invoke `convention-detector`:
+   - Codify the conventions established during scaffolding
+   - Document naming patterns, file organization, and code style
+   - Record testing conventions and patterns
+   - Update `knowledge-base/06-conventions-and-standards.md`
+
+## Rules
+
+- Complete the architectural interview before scaffolding — do not assume technology choices
+- Every architectural decision must be recorded as an ADR
+- The scaffold must be functional — buildable and testable from the start
+- Intelligence initialization must produce evidence-backed artifacts, not templates
+- This workflow creates a new project and modifies the scaffolded project code

package/templates/canonical/workflows/discover-codebase.md

@@ -0,0 +1,60 @@
+---
+description: Autonomously discover and understand an existing codebase through systematic analysis, interactive clarification, and finalized intelligence artifacts — without modifying product code.
+---
+
+# Discover Codebase
+
+Use `codebase-discovery-engine` to build a complete understanding of an existing project, then present findings, resolve ambiguities through clarification, and finalize the intelligence baseline.
+
+## Input
+
+An existing repository to analyze. If the repository path is ambiguous, ask for clarification.
+
+## Output
+
+Finalized codebase understanding captured in intelligence artifacts:
+
+| Category | Path | Content |
+|---|---|---|
+| Knowledge Base | `knowledge-base/` | Evidence-backed project documentation |
+| Graphs | `.engineering-intelligence/graph/` | Architecture graphs and maps |
+| Context | `.engineering-intelligence/context/` | AI navigation maps |
+| Discovery Report | `.engineering-intelligence/reports/DISCOVERY-*.md` | Findings summary with confidence levels |
+
+## Execution Steps
+
+1. **Discover** — Invoke `codebase-discovery-engine` to scan the repository:
+   - Technology stack, frameworks, and runtimes
+   - Project structure and module organization
+   - API surfaces, database schemas, and integrations
+   - Build systems, CI/CD pipelines, and deployment targets
+   - Test infrastructure and coverage
+   - Authentication and authorization patterns
+
+2. **Present Findings** — Surface the discovery results to the user:
+   - Summarize what was found with confidence levels
+   - Highlight areas of uncertainty or ambiguity
+   - Call out architectural patterns and notable design decisions
+   - Identify gaps where information could not be determined from code alone
+
+3. **Ask Clarifications** — For areas with low confidence or ambiguity:
+   - Ask targeted questions about unclear architectural decisions
+   - Confirm assumptions about deployment topology
+   - Verify business domain understanding
+   - Clarify team conventions not evident from code
+
+4. **Finalize Understanding** — Incorporate clarifications and produce final artifacts:
+   - Update knowledge-base documents with confirmed information
+   - Mark remaining unknowns explicitly
+   - Generate architecture graphs via `graph-engine`
+   - Write discovery report with confidence assessment
+
+## Rules
+
+- Begin with automated analysis — ask questions only for genuine ambiguity
+- Every claim must cite evidence from the repository
+- Do not fabricate details — mark uncertainty clearly
+- Present findings before asking clarifications (show work first)
+- This workflow does not modify product code
+
+This workflow does not modify product code. It writes only intelligence artifacts.

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

@@ -4,18 +4,20 @@ description: Implement an engineering request with impact analysis, tests, valid
 
 # Engineering Intelligence
 
-Use the `engineering-intelligence-skill` capability for the user's accompanying request.
+Use the `engineering-intelligence-skill` capability for the user's accompanying request. For non-trivial work, use `aidlc-lifecycle-engine` inside this workflow to merge Agile delivery with AI-DLC durable state.
 
 ## Pipeline
 
 1. **Read Intelligence** — Consult `knowledge-base/`, `.engineering-intelligence/memory/`, `.engineering-intelligence/context/`, `.engineering-intelligence/graph/`
-2. **Write Impact Report** — Create `.engineering-intelligence/reports/IMP-XXX-<summary>.md` before any code edit
-3. **Implement** — Make the requested code changes following established patterns
-4. **Test** — Add/update tests proportional to risk; execute and record results
-5. **Validate** — Run available linters, type checks, and test suites
-6. **Sync Intelligence** — Incrementally update only affected knowledge, memory, context, event, graph artifacts
-7. **Record Change** — Write `.changes/CHG-XXX-<summary>.md` referencing related reports
-8. **Review Gate** — For high-risk changes, run engineering-change review before completion
+2. **Select Delivery Mode** — Choose standard Agile, adversarial, TDD, design-first, or hypothesis debugging based on risk
+3. **Write Impact Report** — Create `.engineering-intelligence/reports/IMP-XXX-<summary>.md` before any code edit
+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
 
 ## Completion Report
 
@@ -25,4 +27,6 @@ Finish with:
 - Affected systems and services
 - Synchronized intelligence artifacts
 - Related reports (IMP-XXX, REV-XXX)
+- Agile artifacts updated (backlog, stories, acceptance criteria, Definition of Done)
 - Unresolved risks or follow-ups
+- AI-DLC breadcrumb (`AI-DLC: <phase> -> <stage> -> <status>`)

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

@@ -19,6 +19,7 @@ Analyzes this repository thoroughly without changing product code. Produces a co
 | Context | `.engineering-intelligence/context/` | 6 compact navigation maps |
 | Events | `.engineering-intelligence/events/` | 5 change-event guidance documents |
 | Graphs | `.engineering-intelligence/graph/` | 4 JSON graphs + architecture-map.md |
+| AI-DLC + Agile | `.engineering-intelligence/aidlc/` | Lifecycle state, audit, discovery placeholders, open questions, Agile backlog/sprint/DoR/DoD, cross-unit discovery log |
 | History | `.changes/CHG-000-initialization.md` | Initialization record |
 
 ## Execution Steps
@@ -29,7 +30,8 @@ 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. **Record** — Write initialization change record
+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
 
 ## Important
 

package/templates/canonical/workflows/scope-requirement.md

@@ -8,17 +8,18 @@ Use the `requirement-scoper` capability to interactively scope and document a us
 
 ## Pipeline
 
-1. **Read Context** — Read `knowledge-base/`, `.engineering-intelligence/memory/`, and `.engineering-intelligence/graph/` mapping files.
-2. **Draft Questions** — Generate 3 to 5 targeted business/tech questions clarifying the requirements.
+1. **Read Context** — Read `knowledge-base/`, `.engineering-intelligence/aidlc/`, `.engineering-intelligence/memory/`, and `.engineering-intelligence/graph/` mapping files.
+2. **Draft Questions** — Generate 3 to 5 targeted business/tech questions clarifying the requirements, user story, acceptance criteria, dependencies, and Definition of Ready.
 3. **Iterate** — Prompt the user for answers in the chat pane.
-4. **Document Scoping** — Create or update `knowledge-base/19-requirements.md` with goals, logic configuration, edge cases, UI structures, and the Q&A log.
-5. **Finalize Prompt** — Output the exact `/engineering-intelligence` command required to build the feature.
+4. **Document Scoping** — Create or update `knowledge-base/19-requirements.md` and `.engineering-intelligence/aidlc/agile/` artifacts with goals, user stories, acceptance criteria, edge cases, dependencies, and the Q&A log.
+5. **Finalize Prompt** — Output the exact `/engineering-intelligence` command required to build the ready story.
 
 ## Completion Report
 
 Finish with:
 - Summary of scoped requirements
 - Location of the requirements document (`knowledge-base/19-requirements.md`)
+- Agile artifacts updated under `.engineering-intelligence/aidlc/agile/`
 - The exact implementation command prompt
 
 **Contract**: This workflow does not modify product code.