@harness-engineering/cli 1.13.0 → 1.13.1

package/dist/agents/skills/claude-code/harness-containerization/SKILL.md

@@ -0,0 +1,284 @@
+# Harness Containerization
+
+> Dockerfile review, Kubernetes manifest validation, and container optimization. Smaller images, safer containers, correct orchestration.
+
+## When to Use
+
+- When reviewing Dockerfiles for image size, security, and layer efficiency
+- When auditing Kubernetes manifests, Helm charts, or docker-compose files
+- On PRs that modify container configuration files
+- NOT for CI/CD pipeline design (use harness-deployment)
+- NOT for infrastructure provisioning (use harness-infrastructure-as-code)
+- NOT for application-level security review (use harness-security-review)
+
+## Process
+
+### Phase 1: SCAN -- Discover Container Configuration
+
+1. **Locate container files.** Search the project for container-related configuration:
+   - `Dockerfile`, `Dockerfile.*` (multi-target builds)
+   - `docker-compose.yml`, `docker-compose.*.yml` (override files)
+   - `.dockerignore`
+   - `k8s/`, `kubernetes/`, `manifests/` directories
+   - `helm/`, `charts/` directories
+   - `skaffold.yaml`, `tilt.json` (dev tooling)
+
+2. **Identify base images.** Parse each Dockerfile for FROM directives:
+   - Record base image name, tag, and digest (if pinned)
+   - Flag images using `latest` tag
+   - Flag images from untrusted registries
+   - Note multi-stage build structure (builder vs. runtime stages)
+
+3. **Inventory Kubernetes resources.** Parse manifest files and record:
+   - Resource types (Deployment, Service, ConfigMap, Secret, Ingress, HPA)
+   - Namespaces used
+   - Image references in pod specs
+   - Resource requests and limits
+   - Volume mounts and persistent volume claims
+
+4. **Detect Helm usage.** If Helm charts exist:
+   - Parse `Chart.yaml` for version and dependencies
+   - Parse `values.yaml` for configurable parameters
+   - Identify template files and their output resource types
+
+5. **Present scan summary:**
+
+   ```
+   Container Scan:
+     Dockerfiles: 2 (app, worker)
+     Compose files: 1 (docker-compose.yml + docker-compose.dev.yml)
+     K8s manifests: 8 resources across 2 namespaces
+     Helm charts: 1 (app chart with 3 subcharts)
+     Base images: node:20-alpine, python:3.12-slim
+   ```
+
+---
+
+### Phase 2: ANALYZE -- Evaluate Best Practices
+
+1. **Analyze Dockerfile layer efficiency.** Check each Dockerfile for:
+   - COPY/ADD placement relative to dependency installation (cache busting)
+   - Multi-stage builds separating build dependencies from runtime
+   - Layer count optimization (combining related RUN commands)
+   - Unnecessary files copied into the image (node_modules, .git, tests)
+   - `.dockerignore` completeness
+
+2. **Check container security posture.** Evaluate:
+   - Running as non-root user (USER directive present)
+   - No secrets in build args or environment variables
+   - Base image currency (is the tag reasonably current)
+   - HEALTHCHECK directive present
+   - Read-only filesystem where possible
+   - No privileged mode in compose or K8s specs
+   - Security contexts in Kubernetes pod specs (runAsNonRoot, readOnlyRootFilesystem)
+
+3. **Evaluate Kubernetes resource definitions.** For each Deployment/StatefulSet:
+   - Resource requests and limits are set (CPU and memory)
+   - Liveness and readiness probes are configured
+   - Pod disruption budgets exist for production workloads
+   - Horizontal pod autoscaler is configured where appropriate
+   - Image pull policy is set (Always for mutable tags, IfNotPresent for digests)
+
+4. **Analyze docker-compose configuration.** Check for:
+   - Service dependency ordering (depends_on with health checks)
+   - Volume mount correctness (host paths vs. named volumes)
+   - Network isolation between services
+   - Environment variable management (env_file vs. inline)
+   - Port mapping conflicts
+
+5. **Check image tag strategy.** Verify:
+   - Production images use immutable tags (semver or digest)
+   - Development images use descriptive tags (branch name, commit SHA)
+   - No `latest` tag in production manifests
+   - Registry URL is consistent across all references
+
+---
+
+### Phase 3: OPTIMIZE -- Recommend Improvements
+
+1. **Recommend image size reduction.** For each Dockerfile:
+   - Switch to minimal base images (alpine, distroless, scratch)
+   - Remove build-only dependencies in multi-stage builds
+   - Use `.dockerignore` to exclude test files, docs, and dev configs
+   - Estimate size savings for each recommendation
+
+2. **Recommend build performance improvements.**
+   - Reorder COPY directives to maximize layer cache hits
+   - Use BuildKit features (cache mounts for package managers)
+   - Split slow-changing layers (OS packages) from fast-changing layers (app code)
+   - Example for Node.js:
+
+     ```dockerfile
+     # Good: dependency layer cached separately
+     COPY package.json package-lock.json ./
+     RUN npm ci --production
+     COPY src/ ./src/
+     ```
+
+3. **Recommend Kubernetes improvements.**
+   - Add missing resource limits with reasonable defaults
+   - Configure probes with appropriate initial delays and periods
+   - Add pod anti-affinity for high-availability workloads
+   - Recommend namespace isolation for multi-tenant clusters
+   - Add network policies to restrict pod-to-pod communication
+
+4. **Recommend security hardening.**
+   - Add non-root USER directive with specific UID
+   - Add security context to Kubernetes pods
+   - Pin base images to digest for supply chain security
+   - Remove unnecessary capabilities (drop ALL, add only what is needed)
+
+5. **Generate optimization summary with estimated impact:**
+
+   ```
+   Optimization Summary:
+     Image size: 850MB -> ~180MB (switch to alpine + multi-stage)
+     Build time: ~4m -> ~2m (layer reordering + cache mounts)
+     Security: 3 findings (non-root, capabilities, image pinning)
+     K8s: 5 resources missing resource limits
+   ```
+
+---
+
+### Phase 4: VALIDATE -- Verify Configuration Correctness
+
+1. **Validate Dockerfile syntax.** Run `docker build --check` or parse for common errors:
+   - Invalid instruction ordering (e.g., CMD before COPY)
+   - Missing required arguments
+   - Deprecated instructions (MAINTAINER)
+   - Shell form vs. exec form for CMD/ENTRYPOINT
+
+2. **Validate Kubernetes manifests.** Check for:
+   - Valid YAML structure
+   - Required fields present (apiVersion, kind, metadata, spec)
+   - Label selectors match between Deployment and Service
+   - Port numbers are consistent across Service and container specs
+   - ConfigMap and Secret references resolve to existing resources
+
+3. **Validate Helm charts.** If Helm is used:
+   - `helm lint` passes
+   - Template rendering with default values produces valid manifests
+   - Values schema matches actual usage in templates
+   - Dependencies are declared and version-locked
+
+4. **Validate docker-compose.** Check for:
+   - Valid YAML and compose file version
+   - All referenced images exist or have build contexts
+   - Port mappings do not conflict
+   - Named volumes are declared in the top-level volumes section
+   - Networks are declared before use
+
+5. **Generate validation report:**
+
+   ```
+   Container Validation: [PASS/WARN/FAIL]
+
+   Dockerfiles: PASS (2/2 valid)
+   K8s manifests: WARN (label mismatch in worker-service.yaml)
+   Helm chart: PASS (lint clean)
+   Compose: PASS (valid structure)
+
+   Issues:
+     1. k8s/worker-service.yaml: selector "app: worker" does not match
+        deployment label "app: worker-v2" -- requests will not route
+   ```
+
+---
+
+## Harness Integration
+
+- **`harness skill run harness-containerization`** -- Primary invocation for container review.
+- **`harness validate`** -- Run after configuration changes to verify project health.
+- **`harness check-deps`** -- Verify container tooling dependencies are available.
+- **`emit_interaction`** -- Present optimization recommendations and gather decisions.
+
+## Success Criteria
+
+- All container configuration files in the project are discovered and cataloged
+- Dockerfiles are analyzed for layer efficiency, security, and size
+- Kubernetes manifests are validated for correctness and best practices
+- Resource requests and limits are verified for all production workloads
+- Image tag strategy is evaluated (no `latest` in production)
+- Optimization recommendations include estimated impact
+
+## Examples
+
+### Example: Node.js Monorepo with Docker and Kubernetes
+
+```
+Phase 1: SCAN
+  Found: Dockerfile (app), Dockerfile.worker, docker-compose.dev.yml
+  K8s: 12 manifests in k8s/ (2 Deployments, 2 Services, 2 ConfigMaps,
+       2 HPA, 2 Ingress, 2 PDB)
+  Base images: node:20 (not alpine), node:20 (worker)
+
+Phase 2: ANALYZE
+  Dockerfile issues:
+    - node:20 full image (940MB) -- use node:20-alpine (180MB)
+    - No .dockerignore -- node_modules and .git copied into image
+    - No USER directive -- running as root
+    - No HEALTHCHECK
+  K8s issues:
+    - worker deployment missing memory limits
+    - No network policies defined
+    - Liveness probe on /healthz but no readiness probe
+
+Phase 3: OPTIMIZE
+  1. Switch to node:20-alpine -- saves ~760MB per image
+  2. Add .dockerignore with node_modules, .git, tests, docs
+  3. Add multi-stage build: builder stage for npm ci, runtime for app
+  4. Add USER node (UID 1000) after COPY
+  5. Add readiness probe on /ready endpoint
+  6. Add memory limit of 512Mi to worker deployment
+
+Phase 4: VALIDATE
+  Dockerfiles: WARN (2 security findings, 1 size finding)
+  K8s manifests: WARN (missing limits, missing readiness probe)
+  Compose: PASS
+  Result: WARN -- 6 actionable improvements identified
+```
+
+### Example: Python FastAPI with Helm and Distroless
+
+```
+Phase 1: SCAN
+  Found: Dockerfile (multi-stage with distroless runtime)
+  Helm chart: charts/api/ with values.yaml
+  Base images: python:3.12-slim (builder), gcr.io/distroless/python3 (runtime)
+
+Phase 2: ANALYZE
+  Dockerfile: Well-structured multi-stage build
+    - Builder installs dependencies, runtime copies only venv
+    - Distroless base (no shell, minimal attack surface)
+    - Non-root user configured
+  Helm:
+    - Resource limits set in values.yaml
+    - Probes configured with appropriate timeouts
+    - HPA configured for 2-10 replicas
+
+Phase 3: OPTIMIZE
+  Minor recommendations only:
+    - Pin distroless image to digest for reproducibility
+    - Add --mount=type=cache for pip downloads in builder stage
+    - Add pod anti-affinity to spread replicas across nodes
+
+Phase 4: VALIDATE
+  Dockerfile: PASS
+  Helm lint: PASS
+  Template render: PASS (all values resolve)
+  Result: PASS -- well-configured container setup
+```
+
+## Gates
+
+- **No `latest` tag in production manifests.** Production Kubernetes manifests or compose files using `latest` image tags are blocking findings. Immutable tags or digests are required.
+- **No containers running as root in production.** Missing USER directive in Dockerfiles or missing security context in K8s pods targeting production are blocking findings.
+- **No missing resource limits in production.** Kubernetes Deployments without CPU and memory limits are blocking warnings for production namespaces.
+- **No invalid manifest references.** Label selector mismatches between Services and Deployments, or ConfigMap/Secret references to nonexistent resources, are blocking errors.
+
+## Escalation
+
+- **When base images have known CVEs:** Flag the specific CVEs and recommend upgrading to a patched version. If no patched version exists, recommend an alternative base image and document the migration path.
+- **When Kubernetes manifest complexity exceeds review scope:** For clusters with 50+ resources, recommend focusing on changed resources only (`--changed-only` flag) and scheduling a full audit separately.
+- **When Helm chart dependencies are outdated:** Report the version gap and recommend updating. If the update includes breaking changes, flag it as a decision point and present the changelog.
+- **When docker-compose is used for production:** Flag this as an architectural concern. Docker Compose is appropriate for development but production workloads should use an orchestrator (Kubernetes, ECS, Cloud Run). Present migration options.

package/dist/agents/skills/claude-code/harness-containerization/skill.yaml

@@ -0,0 +1,80 @@
+name: harness-containerization
+version: "1.0.0"
+description: Dockerfile review, Kubernetes manifests, container registry management
+cognitive_mode: meticulous-verifier
+tier: 3
+internal: false
+keywords:
+  - Docker
+  - Dockerfile
+  - Kubernetes
+  - K8s
+  - container
+  - pod
+  - service
+  - deployment
+  - Helm
+  - registry
+  - image
+  - multi-stage
+  - docker-compose
+stack_signals:
+  - "Dockerfile"
+  - "docker-compose.*"
+  - "k8s/"
+  - "kubernetes/"
+  - "helm/"
+  - "charts/"
+  - ".dockerignore"
+  - "skaffold.yaml"
+triggers:
+  - manual
+  - on_pr
+  - on_commit
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - emit_interaction
+cli:
+  command: harness skill run harness-containerization
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: scope
+      description: Scope of review (dockerfile, k8s, compose, all)
+      required: false
+    - name: fix
+      description: Auto-fix common issues (layer ordering, security)
+      type: boolean
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-containerization
+    path: string
+type: rigid
+phases:
+  - name: scan
+    description: Discover container configuration files and registry references
+    required: true
+  - name: analyze
+    description: Evaluate Dockerfiles, manifests, and compose files for best practices
+    required: true
+  - name: optimize
+    description: Recommend image size, layer, and security improvements
+    required: true
+  - name: validate
+    description: Verify configurations are correct and deployable
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/harness-data-pipeline/SKILL.md

@@ -0,0 +1,274 @@
+# Harness Data Pipeline
+
+> Verify ETL/ELT pipeline quality, data contracts, idempotency, and test coverage. Analyzes DAG structure, transformation logic, and data quality checks across dbt, Airflow, Dagster, and Prefect pipelines.
+
+## When to Use
+
+- When reviewing a PR that modifies pipeline definitions, DAGs, or transformation logic
+- When adding new data sources or sinks to an existing pipeline
+- When data quality issues surface and pipeline validation needs auditing
+- NOT for database schema design or migration review (use harness-database)
+- NOT for SQL query optimization within pipelines (use harness-sql-review)
+- NOT for infrastructure provisioning of pipeline runners (use harness-infrastructure-as-code)
+
+## Process
+
+### Phase 1: DETECT -- Identify Pipeline Framework and Structure
+
+1. **Resolve project root.** Use provided path or cwd.
+
+2. **Detect pipeline framework.** Scan for framework indicators:
+   - **dbt:** `dbt_project.yml`, `profiles.yml`, `models/` with `.sql` files, `macros/`
+   - **Airflow:** `dags/` directory, files importing `from airflow`, `airflow.cfg`
+   - **Dagster:** `dagster/` directory, files importing `from dagster`, `workspace.yaml`
+   - **Prefect:** files importing `from prefect`, `prefect.yaml`, `flows/`
+   - **Custom:** `pipelines/`, `etl/`, `src/**/transforms/**` without known framework markers
+
+3. **Map DAG structure.** For the detected framework:
+   - **dbt:** Parse `ref()` and `source()` calls to build the model dependency graph
+   - **Airflow:** Parse `>>` operators and `set_downstream/set_upstream` calls to build task dependencies
+   - **Dagster:** Parse `@asset` decorators and `deps` parameters to build the asset graph
+   - **Prefect:** Parse `@flow` and `@task` decorators to build the flow graph
+
+4. **Identify data sources and sinks.** Catalog:
+   - Source systems (databases, APIs, file systems, message queues)
+   - Sink targets (data warehouses, data lakes, downstream services)
+   - Intermediate staging areas
+
+5. **Detect configuration.** Read pipeline configuration for:
+   - Schedule/cron definitions
+   - Retry policies and timeout settings
+   - Environment-specific overrides (dev, staging, production)
+   - Secret references and connection strings
+
+6. **Report detection summary:**
+   ```
+   Framework: dbt 1.7 + Airflow 2.8
+   Models: 45 dbt models (12 staging, 18 intermediate, 15 mart)
+   DAGs: 3 Airflow DAGs (daily-etl, hourly-metrics, weekly-reports)
+   Sources: 2 PostgreSQL databases, 1 S3 bucket, 1 Stripe API
+   Sinks: BigQuery (analytics warehouse)
+   ```
+
+---
+
+### Phase 2: ANALYZE -- Evaluate Pipeline Patterns
+
+1. **Check idempotency.** For each pipeline/model:
+   - Does the transformation produce the same result when run multiple times?
+   - Are there `INSERT` operations without corresponding `DELETE` or `MERGE` logic?
+   - Are dbt models using `incremental` materialization with proper `unique_key`?
+   - Do Airflow tasks use idempotent operators or handle re-runs gracefully?
+
+2. **Check error handling.** Evaluate:
+   - Are failed tasks retried with backoff? (Airflow: `retries`, `retry_delay`; Prefect: `retries`, `retry_delay_seconds`)
+   - Is there alerting on pipeline failure? (Slack, PagerDuty, email callbacks)
+   - Are partial failures handled? (Can the pipeline resume from the point of failure?)
+   - Are dead-letter queues or error tables configured for unprocessable records?
+
+3. **Check data contracts.** Verify schema enforcement:
+   - Are source schemas validated before transformation? (dbt: `source` tests; custom: schema validation)
+   - Are output schemas enforced? (dbt: `contracts`; custom: schema assertions)
+   - Are breaking changes to source schemas detected? (freshness checks, schema drift detection)
+   - Are there column-level descriptions and documentation?
+
+4. **Check pipeline dependencies.** Analyze the DAG for:
+   - Circular dependencies (error: pipeline cannot complete)
+   - Overly long critical paths (warning: bottleneck risk)
+   - Disconnected subgraphs (info: may indicate orphaned pipelines)
+   - Fan-out bottlenecks (one task blocking many downstream tasks)
+
+5. **Check freshness and SLAs.** Evaluate:
+   - Are `freshness` checks defined for sources? (dbt: `loaded_at_field`, `warn_after`, `error_after`)
+   - Are pipeline SLAs defined? (Airflow: `sla` parameter)
+   - Do SLAs match business requirements?
+   - Is there monitoring for SLA breaches?
+
+6. **Classify findings by severity:**
+   - **Error:** Non-idempotent writes, circular dependencies, missing error handling for production DAGs
+   - **Warning:** Missing freshness checks, no retry policy, missing data contracts
+   - **Info:** Undocumented models, missing column descriptions, suboptimal materialization strategy
+
+---
+
+### Phase 3: VALIDATE -- Check Data Quality and Test Coverage
+
+1. **Audit existing data tests.** For each framework:
+   - **dbt:** Count tests per model (`unique`, `not_null`, `accepted_values`, `relationships`, custom)
+   - **Airflow:** Check for data validation tasks in DAGs
+   - **Dagster:** Check for `@asset_check` decorators and `check_specs`
+   - **Custom:** Look for assertion functions, validation scripts, or test files
+
+2. **Calculate test coverage.** Measure:
+   - Models/tasks with zero tests (critical gap)
+   - Models with only generic tests (not_null, unique) but no business logic tests
+   - Primary key coverage: does every model test uniqueness on its grain?
+   - Referential integrity: are foreign key relationships tested?
+
+3. **Check for missing critical tests.** Flag models that should have specific tests:
+   - Revenue/financial models: must have row count variance checks and sum validation
+   - User-facing models: must have not_null on required display fields
+   - Incremental models: must have uniqueness test on the incremental key
+   - Models with `WHERE` clauses: must have tests verifying the filter logic
+
+4. **Validate pipeline testability.** Assess:
+   - Can pipelines run in a test environment with mock data?
+   - Are there integration tests that run the full pipeline on sample datasets?
+   - Is there a CI pipeline that runs dbt tests / DAG validation on every PR?
+
+5. **Check for data quality patterns:**
+   - Row count anomaly detection (sudden drops or spikes)
+   - Schema drift detection (new columns, type changes)
+   - Null rate monitoring (percentage of nulls exceeding threshold)
+   - Value distribution monitoring (categorical values outside expected set)
+
+---
+
+### Phase 4: DOCUMENT -- Generate Pipeline Documentation
+
+1. **Generate pipeline lineage report.** Produce a text-based lineage visualization:
+
+   ```
+   source.stripe.payments
+     -> stg_payments (staging, view)
+       -> int_payments_enriched (intermediate, table)
+         -> mart_revenue_daily (mart, incremental)
+           -> [exposed to: Looker dashboard, finance API]
+   ```
+
+2. **Generate quality check report.** Summarize test coverage and findings:
+
+   ```
+   Pipeline Quality Report: [PASS/NEEDS_ATTENTION/FAIL]
+   Models: 45 total
+   Test coverage: 78% (35/45 models have tests)
+   Critical gaps: 3 models with zero tests (mart_revenue_daily, stg_users, int_orders)
+   Data contracts: 12/15 mart models have contracts
+   Freshness checks: 4/6 sources have freshness monitoring
+
+   ERRORS:
+   [DP-ERR-001] models/marts/mart_revenue_daily.sql
+     Non-idempotent: uses INSERT without MERGE or DELETE+INSERT pattern
+   [DP-ERR-002] dags/daily_etl.py
+     No retry policy: tasks will not retry on transient failures
+
+   WARNINGS:
+   [DP-WARN-001] models/staging/stg_users.sql
+     Zero tests: no data quality checks on user staging model
+   [DP-WARN-002] sources.yml
+     Missing freshness: stripe.payments source has no freshness check
+   ```
+
+3. **Generate missing documentation.** For undocumented models:
+   - Create `schema.yml` entries with inferred column descriptions
+   - Add model descriptions based on SQL logic analysis
+   - Document source-to-mart lineage
+
+4. **Produce remediation checklist.** Prioritized list of actions:
+
+   ```
+   Priority 1 (errors):
+   [ ] Fix mart_revenue_daily to use MERGE for idempotency
+   [ ] Add retry policy to daily_etl DAG tasks
+
+   Priority 2 (warnings):
+   [ ] Add not_null and unique tests to stg_users
+   [ ] Add freshness check to stripe.payments source
+
+   Priority 3 (info):
+   [ ] Add column descriptions to 12 undocumented models
+   [ ] Document the weekly-reports DAG purpose and schedule
+   ```
+
+---
+
+## Harness Integration
+
+- **`harness skill run harness-data-pipeline`** -- Primary command for pipeline quality auditing.
+- **`harness validate`** -- Run after applying pipeline changes to verify project health.
+- **`Glob`** -- Used to locate DAG files, model definitions, configuration files, and test specifications.
+- **`Grep`** -- Used to find `ref()` calls, `source()` references, operator chains, and test definitions.
+- **`Read`** -- Used to read pipeline definitions, SQL models, configuration files, and test results.
+- **`Write`** -- Used to generate documentation stubs, schema.yml entries, and quality reports.
+- **`Bash`** -- Used to run `dbt ls`, `dbt test --dry-run`, or parse DAG structures.
+- **`emit_interaction`** -- Used to present the quality report and confirm remediation priorities.
+
+## Success Criteria
+
+- Pipeline framework is correctly detected with full DAG structure mapped
+- Every model/task is evaluated for idempotency, error handling, and data contracts
+- Test coverage percentage is calculated with critical gaps identified
+- Lineage is documented from source to mart/exposure
+- Findings are classified by severity with specific remediation steps
+- Quality report follows structured format suitable for team review
+
+## Examples
+
+### Example: dbt Project with BigQuery Warehouse
+
+```
+Phase 1: DETECT
+  Framework: dbt 1.7.4 (dbt-bigquery adapter)
+  Models: 52 (15 staging, 22 intermediate, 15 mart)
+  Sources: 3 (PostgreSQL replica, Stripe API via Fivetran, Google Sheets)
+  Target: BigQuery dataset `analytics`
+
+Phase 2: ANALYZE
+  [DP-ERR-001] models/marts/mart_subscriptions.sql
+    Incremental model missing unique_key -- will create duplicates on re-run
+  [DP-WARN-001] 4 sources missing freshness checks
+  [DP-WARN-002] No retry configuration in dbt Cloud job settings
+
+Phase 3: VALIDATE
+  Test coverage: 71% (37/52 models)
+  Critical gaps: mart_revenue (no tests), mart_subscriptions (no uniqueness test)
+  Primary key coverage: 80% (missing on 3 intermediate models)
+
+Phase 4: DOCUMENT
+  Generated: lineage report for all 52 models
+  Generated: schema.yml stubs for 8 undocumented models
+  Quality Report: NEEDS_ATTENTION (1 error, 4 warnings)
+```
+
+### Example: Airflow DAGs with S3-to-Snowflake Pipeline
+
+```
+Phase 1: DETECT
+  Framework: Apache Airflow 2.8.1
+  DAGs: 5 (s3_ingest_daily, transform_orders, aggregate_metrics, export_reports, cleanup)
+  Sources: S3 buckets (raw-events, partner-feeds), PostgreSQL
+  Sinks: Snowflake (ANALYTICS schema), S3 (processed-exports)
+
+Phase 2: ANALYZE
+  [DP-ERR-001] dags/s3_ingest_daily.py
+    S3KeySensor has no timeout -- will block the scheduler indefinitely
+  [DP-ERR-002] dags/transform_orders.py
+    PythonOperator writes to Snowflake without transaction -- partial writes on failure
+  [DP-WARN-001] dags/cleanup.py
+    No SLA defined -- cleanup failures could go unnoticed for days
+  [DP-INFO-001] All DAGs use default_args but 2 override retries to 0
+
+Phase 3: VALIDATE
+  DAG validation: all 5 parse without errors
+  Data validation tasks: present in 3/5 DAGs
+  Missing: no validation in s3_ingest_daily (raw data accepted without checks)
+
+Phase 4: DOCUMENT
+  Generated: DAG dependency diagram
+  Generated: runbook for each DAG with schedule, dependencies, and failure recovery
+  Quality Report: FAIL (2 errors requiring immediate attention)
+```
+
+## Gates
+
+- **No approving non-idempotent production pipelines.** If a pipeline writes data without MERGE, upsert, or delete-then-insert patterns, it is flagged as an error. Non-idempotent pipelines cause data duplication on re-runs.
+- **No ignoring circular dependencies.** Circular dependencies in the DAG mean the pipeline cannot complete. This is always an error, never a warning.
+- **No passing pipelines with zero test coverage on financial models.** Models that feed revenue reports, billing, or financial dashboards must have data quality tests. Zero coverage on these models is an error.
+- **No generating documentation that misrepresents lineage.** If the lineage cannot be confidently traced (e.g., dynamic SQL, runtime-generated table names), mark it as "unresolved" rather than guessing.
+
+## Escalation
+
+- **When pipeline logic uses dynamic SQL or runtime table names:** Flag that lineage cannot be statically analyzed: "This model uses `{{ var('target_table') }}` which resolves at runtime. Manual lineage documentation is required."
+- **When data quality issues indicate upstream source problems:** Do not attempt to fix source data. Report: "Source `stripe.payments` has 15% null `customer_id` values. This is a source data quality issue -- coordinate with the data provider."
+- **When pipeline SLAs conflict with infrastructure capacity:** If the pipeline takes longer than its schedule interval, flag the scheduling conflict: "daily_etl takes ~4 hours but is scheduled every 2 hours. This will cause overlapping runs."
+- **When migration from one framework to another is in progress:** If both Airflow and Dagster artifacts exist, ask for clarification rather than analyzing both: "Found both Airflow DAGs and Dagster assets. Which framework should be audited? Is a migration in progress?"