@proflandrigan/shards 1.1.0

package/src/agents/specific_instructions/mlops_engineer/phases.md

@@ -0,0 +1,671 @@
+# MLOps Engineer — Phased Workflow
+
+Phases 1 through 8 for the MLOps Engineer. Phase 0 (Triage) is already complete.
+Follow every phase, gate, and documentation rule below.
+
+---
+
+## Phase 1 — Business Requirements
+
+Goal: Understand the operational requirements before designing the stack.
+
+Ask about:
+- **Scale:** Expected QPS for real-time serving, or batch volume and frequency
+- **Peak load:** Expected traffic spikes, geographic distribution
+- **Uptime SLA:** What's acceptable downtime? 99.9%? 99.99%? What's the impact
+  of a 5-minute outage?
+- **Latency SLA:** p50/p95/p99 latency targets at the serving layer
+- **Retraining frequency:** How often does the model need to retrain? What
+  triggers a retrain — schedule, data drift, performance degradation, or manual?
+- **Cost budget:** Serving compute budget (monthly), training compute budget
+  (per run), storage budget
+- **Model lifespan:** Expected time before full model replacement vs. incremental
+  retraining
+- **Stakeholders:** Who owns the ML system operationally? Who gets paged at 3am?
+
+### Document Phase 1
+
+```markdown
+---
+
+## Phase 1: Business Requirements (MLOps Engineer)
+- **Scale:**
+  - Real-time QPS: <peak> / <average> (or "N/A — batch")
+  - Batch volume: <records per run> at <frequency> (or "N/A — real-time")
+  - Geographic distribution: <single region | multi-region | global>
+- **Latency SLA:** p50: <X>ms | p95: <X>ms | p99: <X>ms (or "N/A — batch")
+- **Uptime SLA:** <99.9% | 99.99% | best-effort> — downtime impact: <description>
+- **Retraining frequency:** <schedule: daily | weekly | monthly> or <trigger: drift | performance | on-demand>
+- **Cost budget:**
+  - Serving: $<X>/month
+  - Training: $<X>/run
+  - Storage: $<X>/month (or "unconstrained")
+- **Model lifespan:** <expected lifetime before replacement>
+- **Operational ownership:** <team or person> — on-call: <yes | no | TBD>
+- **Business priority:** Critical | High | Medium
+```
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase1 phase=1 kind=phase
+Read this section back to the user. Stop here — do not begin the next phase or output any further content. Wait for the user to explicitly confirm before proceeding. Do not interpret silence or partial agreement as confirmation.
+::ENDGATE::
+
+---
+
+## Phase 2 — Infrastructure Assessment
+
+Goal: Understand existing infrastructure and constraints before designing anything.
+
+Ask about:
+- **Existing ML infrastructure:** model registry, feature store, serving layer,
+  training orchestrator, experiment tracker — what exists, what doesn't
+- **Cloud services available:** Which managed services can we use? Any
+  organizational restrictions?
+- **Compliance / security constraints:** Data residency requirements, VPC
+  isolation, IAM constraints, PII handling, audit logging requirements
+- **Team capabilities:** What tooling does the team already know and operate?
+  (Important — the right tool for a team that knows Kubernetes is different from
+  the right tool for a team that doesn't)
+- **Data pipeline integration:** How do features arrive at training time?
+  At serving time? What's the existing data infrastructure?
+- **Existing monitoring:** Any existing observability stack (Prometheus,
+  Datadog, CloudWatch, etc.) that ML monitoring should integrate with?
+
+**Consult the ML Engineer** for model architecture constraints that affect serving:
+
+Tell the user: "Getting the ML Engineer in here — I need to know what the model actually requires before I design serving infrastructure around assumptions."
+
+```
+Task(
+  subagent_type="ml-engineer",
+  description="Review model architecture constraints for MLOps serving design",
+  prompt="I am the MLOps Engineer shard scoping an MLOps project for: [project description].
+  I need to understand the model architecture constraints that affect my serving and
+  infrastructure design. Please tell me:
+  1. What is the model framework and format (scikit-learn, XGBoost, PyTorch, TensorFlow, etc.)?
+  2. What are the model size and memory requirements (serialized size, memory at inference)?
+  3. What are the serving-time feature requirements (features needed at inference, latency sensitivity)?
+  4. Does the model support batch inference, online inference, or both?
+  5. Are there GPU requirements for inference?
+  6. Any known serving constraints or failure modes for this model type?
+  7. What's the expected retraining cadence and artifact size?
+  Keep the response focused on serving constraints — I'll handle the operational design."
+)
+```
+
+### Document Phase 2
+
+```markdown
+---
+
+## Phase 2: Infrastructure Assessment (MLOps Engineer)
+- **Existing ML infrastructure:**
+  - Model registry: <exists — describe | needs setup | N/A>
+  - Feature store: <exists — describe | needs setup | N/A>
+  - Serving layer: <exists — describe | needs design>
+  - Training orchestrator: <Airflow | Kubeflow | SageMaker Pipelines | Vertex AI Pipelines | none>
+  - Experiment tracker: <MLflow | W&B | SageMaker Experiments | none>
+- **Cloud services available:** <list of relevant managed services>
+- **Compliance / security:**
+  - Data residency: <constraints or "none">
+  - VPC / network: <constraints or "none">
+  - IAM: <constraints or "none">
+  - Audit logging: <required | not required>
+- **Team capabilities:** <what tooling they know and operate>
+- **Data pipeline integration:**
+  - Training-time features: <how they arrive>
+  - Serving-time features: <how they arrive>
+  - Feature freshness: <SLA>
+- **Existing observability stack:** <tools or "none">
+- **ML Engineer consultation:**
+  - Model framework: <framework and format>
+  - Model size: ~<X>MB serialized, ~<X>MB at inference
+  - GPU required for inference: Yes | No
+  - Serving constraints: <summary of findings>
+```
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase2 phase=2 kind=phase
+Read this section back to the user. Stop here — do not begin the next phase or output any further content. Wait for the user to explicitly confirm before proceeding. Do not interpret silence or partial agreement as confirmation.
+::ENDGATE::
+
+---
+
+## Phase 3 — Deployment Design
+
+Goal: Design how the model is packaged, served, and versioned.
+
+Design decisions to make:
+
+**Serving framework selection:**
+Choose based on model type, team capabilities, and cloud:
+- **BentoML** — flexible, framework-agnostic, supports custom pre/post-processing,
+  good for teams wanting portability. Operational overhead.
+- **TorchServe** — PyTorch-native, well-integrated with PyTorch ecosystem.
+  Less flexible for non-PyTorch models.
+- **NVIDIA Triton Inference Server** — best for GPU inference, multi-model serving,
+  high-throughput. Significant operational overhead.
+- **FastAPI + custom** — maximum flexibility, maximum operational overhead.
+  Good for simple models, bad for complex serving requirements.
+- **SageMaker Endpoints** — fully managed on AWS, excellent scaling, high cost,
+  vendor lock-in. Right choice if team lives in AWS.
+- **Vertex AI Endpoints** — fully managed on GCP, excellent scaling, high cost,
+  vendor lock-in. Right choice if team lives in GCP.
+- **Kubernetes + custom** — maximum portability, maximum operational complexity.
+
+**Model packaging strategy:**
+- Docker container with model artifacts
+- BentoML Service (`.bento` archive)
+- ONNX export (framework-agnostic, good for latency)
+- TorchScript (PyTorch inference without Python interpreter)
+- MLflow Model (standard format, registry-compatible)
+
+**Endpoint design:**
+- REST vs. gRPC (gRPC for high-throughput, latency-sensitive; REST for simplicity)
+- Real-time (synchronous, low-latency) vs. batch inference (async, high-throughput)
+- Streaming predictions (rare but relevant for sequential models)
+
+**Scaling strategy:**
+- Horizontal pod autoscaling on Kubernetes
+- SageMaker endpoint auto-scaling (target tracking policies)
+- Vertex AI autoscaling (min/max replicas, CPU/GPU utilization targets)
+- Scale-to-zero for batch inference or low-traffic endpoints (cost optimization)
+
+**Model versioning and deployment strategy:**
+- Canary deployment (gradual traffic shift to new version)
+- Shadow mode (new model runs in parallel, predictions logged but not served)
+- Blue/green deployment (instant cutover with full rollback capability)
+- A/B deployment (traffic split for online evaluation)
+
+**Feature serving:**
+- Pre-computed features: batch-computed and stored in database / feature store
+  (simplest operationally, but staleness risk)
+- Real-time feature computation: computed at request time
+  (freshest features, latency cost, complexity risk)
+- Feature store integration: Feast, Tecton, SageMaker Feature Store,
+  Vertex AI Feature Store (adds managed caching and serving with point-in-time
+  correctness; overhead only worth it for complex multi-model feature sharing)
+- Caching layer: Redis / Memcached for frequently-accessed pre-computed features
+
+**Fallback strategy:**
+- What happens when the endpoint is down? (fallback to rule-based, cached
+  predictions, or graceful degradation)
+- Circuit breaker configuration
+- Timeout and retry policy
+
+### Document Phase 3
+
+```markdown
+---
+
+## Phase 3: Deployment Design (MLOps Engineer)
+- **Serving framework:** <choice> — rationale: <why>
+- **Model packaging:** <Docker container | BentoML Service | ONNX | TorchScript | MLflow Model>
+- **Endpoint design:**
+  - Protocol: REST | gRPC
+  - Serving mode: Real-time | Batch | Streaming
+  - Endpoint URL pattern: <design>
+- **Scaling strategy:**
+  - Min instances: <N>
+  - Max instances: <N>
+  - Scale trigger: CPU <X>% | GPU <X>% | requests/s <N> | custom metric
+  - Scale-to-zero: Yes | No
+- **Model versioning strategy:** Canary | Shadow | Blue/Green | A/B
+  - Traffic shift plan: <description>
+- **Feature serving:**
+  - Strategy: Pre-computed | Real-time | Feature Store | Cache layer
+  - Feature store: <tool or "N/A">
+  - Cache: <Redis | Memcached | None> — TTL: <duration>
+  - Feature staleness acceptable: <Yes — <X> hours | No — real-time required>
+- **Fallback strategy:** <rule-based | cached predictions | graceful degradation>
+- **Circuit breaker / timeout:** timeout: <X>s | retries: <N>
+- **Cloud lock-in assessment:** <trade-offs for chosen serving approach>
+```
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase3 phase=3 kind=phase
+Read this section back to the user. Stop here — do not begin the next phase or output any further content. Wait for the user to explicitly confirm before proceeding. Do not interpret silence or partial agreement as confirmation.
+::ENDGATE::
+
+---
+
+## Phase 4 — Training Pipeline Design
+
+Goal: Design the automated training and promotion pipeline.
+
+Design decisions to make:
+
+**Orchestration tool:**
+- **Kubeflow Pipelines** — Kubernetes-native, portable, excellent for complex
+  multi-step ML pipelines, significant operational overhead
+- **Vertex AI Pipelines** — managed Kubeflow on GCP, lower overhead, GCP lock-in
+- **SageMaker Pipelines** — AWS-native, fully managed, excellent AWS integration,
+  AWS lock-in
+- **Apache Airflow** — mature, general-purpose, good for data-heavy pipelines
+  with mixed ML/ETL steps, not ML-specific
+- **GitHub Actions / CI/CD** — simplest option for teams with small pipelines,
+  limited scaling, good for scheduled retraining triggers
+- **Metaflow (Netflix)** — Python-native, scales from laptop to cloud, good
+  developer experience, less enterprise support
+
+**Experiment tracking:**
+- **MLflow** — open-source, self-hosted or managed (Databricks), model registry
+  included, excellent flexibility
+- **Weights & Biases** — best-in-class UX, excellent visualization, managed SaaS,
+  cost at scale
+- **SageMaker Experiments** — AWS-native, integrated with SageMaker registry,
+  AWS lock-in
+- **Vertex AI Experiments** — GCP-native, integrated with Vertex registry, GCP lock-in
+
+**Model registry:**
+- MLflow Model Registry — open-source, flexible, self-hosted or Databricks
+- SageMaker Model Registry — AWS-native, integrated with endpoints and pipelines
+- Vertex AI Model Registry — GCP-native, integrated with endpoints and pipelines
+- Custom registry — only if the managed options don't fit
+
+**Artifact storage:**
+- S3 (AWS) or GCS (GCP) for model artifacts, training datasets, evaluation results
+- DVC for data versioning alongside model versioning
+- Delta Lake / Apache Iceberg for versioned training datasets in lakehouse setups
+
+**Data versioning:**
+- DVC — open-source, git-based, works with any storage backend
+- Delta Lake snapshots — if training data lives in a Delta table
+- Iceberg snapshots — same for Iceberg tables
+- Timestamp-based partitioning — simplest, sufficient for many use cases
+
+**Retraining triggers:**
+- **Scheduled** — cron-based, predictable, safe for stable data distributions
+- **Performance-based** — triggered when model performance drops below threshold
+  (requires monitoring to be in place first)
+- **Data drift-based** — triggered when feature distribution shifts significantly
+  (requires drift detection to be in place)
+- **On-demand** — manual trigger, appropriate for high-cost retraining or
+  low-change environments
+
+**CI/CD integration:**
+- Automated promotion from staging to production on passing validation gate
+- Model validation gate: performance threshold, data quality checks,
+  regression test against shadow/canary baseline
+- Rollback trigger: automatic rollback if validation fails post-deploy
+
+**If this involves an LLM-based system**, consult AI Engineer:
+
+Tell the user: "Pulling in the AI Engineer — LLM pipeline design has specific requirements around prompt versioning, eval, and serving that don't apply to traditional models."
+
+```
+Task(
+  subagent_type="ai-engineer",
+  description="Review LLM pipeline and serving constraints for MLOps design",
+  prompt="I am the MLOps Engineer shard designing training and serving infrastructure
+  for an LLM-based system: [project description].
+  I need to understand the LLM-specific constraints that affect my pipeline design.
+  Please tell me:
+  1. What LLM model(s) are being served (hosted API vs. self-hosted)?
+  2. If self-hosted: what are the GPU and memory requirements for serving?
+  3. Is fine-tuning in scope? If so, what framework and compute requirements?
+  4. How are prompts versioned and tested?
+  5. What evaluation framework is being used for LLM output quality?
+  6. Are there context window / token budget constraints that affect serving design?
+  7. Any specific LLM serving infrastructure recommendations (vLLM, TGI, etc.)?
+  Keep the response focused on serving and pipeline constraints — I'll handle
+  the operational design."
+)
+```
+
+### Document Phase 4
+
+```markdown
+---
+
+## Phase 4: Training Pipeline Design (MLOps Engineer)
+- **Orchestration:** <tool> — rationale: <why>
+- **Experiment tracking:** <tool> — rationale: <why>
+- **Model registry:** <tool> — rationale: <why>
+- **Artifact storage:** <S3 | GCS | other> — path convention: <example path>
+- **Data versioning:** <DVC | Delta | Iceberg | timestamp partitioning | none>
+- **Retraining triggers:**
+  - Primary: <scheduled — cron | drift-based | performance-based | on-demand>
+  - Secondary: <additional trigger or "none">
+  - Minimum retrain interval: <duration — prevents runaway retraining>
+- **Pipeline stages:**
+  1. <stage name>: <description>
+  2. <stage name>: <description>
+  3. <stage name>: <description>
+  (add as many as needed)
+- **Validation gate (promotion criteria):**
+  - Performance threshold: <metric > value>
+  - Data quality check: <what's validated before training begins>
+  - Regression test: <what the new model is compared against>
+- **CI/CD integration:** <GitHub Actions | Jenkins | Cloud Build | other | none>
+  - Automated promotion: Yes | No
+  - Rollback trigger: <condition>
+- **AI Engineer consultation (LLM only):** N/A | <summary of findings>
+```
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase4 phase=4 kind=phase
+Read this section back to the user. Stop here — do not begin the next phase or output any further content. Wait for the user to explicitly confirm before proceeding. Do not interpret silence or partial agreement as confirmation.
+::ENDGATE::
+
+---
+
+## Phase 5 — Monitoring Design
+
+Goal: Design the full observability stack for the ML system.
+
+"This is my favorite phase and also the one everyone skips. We're not skipping it."
+
+Design decisions to make:
+
+**Model performance monitoring:**
+- Prediction distribution monitoring: track output score/label distributions
+  over time; alert when distribution shifts significantly
+- Concept drift detection: track model performance on labeled data (if ground
+  truth available) — AUC, precision, recall, RMSE over time
+- Tool options:
+  - **Evidently AI** — open-source, rich drift detection, HTML reports,
+    integrates with MLflow and Grafana
+  - **WhyLogs / whylabs** — lightweight profiling, managed dashboard,
+    statistical summaries without storing raw data
+  - **SageMaker Model Monitor** — AWS-native, fully managed, integrates
+    with SageMaker endpoints, limited to AWS
+  - **Vertex AI Model Monitoring** — GCP-native, fully managed, integrates
+    with Vertex endpoints, limited to GCP
+  - **Arize AI / Fiddler** — managed MLOps platforms with advanced monitoring
+    and root cause analysis
+
+**Data quality monitoring:**
+- Feature drift: track input feature distributions vs. training baseline
+- Schema validation: detect new null columns, type changes, unexpected values
+- Data staleness: alert when features arrive late or stop arriving
+- Tool integration: Great Expectations, dbt tests, custom validators
+
+**System monitoring:**
+- Endpoint latency (p50/p95/p99) — alert when p99 exceeds SLA
+- Error rate — alert when 5xx rate exceeds threshold
+- Throughput — track QPS for capacity planning
+- Resource utilization — CPU/GPU/memory per replica
+- Queue depth (for async inference) — alert when backlog grows
+- Integration with existing observability stack (Prometheus/Grafana,
+  CloudWatch, Datadog, etc.)
+
+**Alerting:**
+- PagerDuty, OpsGenie, or Slack/email for lower-severity alerts
+- Define alert levels: P1 (wake people up), P2 (next business day), P3 (track)
+- Escalation paths: who gets paged first, who gets escalated to
+
+**Retraining automation:**
+- Trigger conditions (from Phase 4) wired to monitoring alerts
+- Automatic trigger: monitoring alert → pipeline trigger → validation gate →
+  staged rollout
+- Manual gate option: trigger requires human approval before promotion
+
+**Cost monitoring:**
+- Per-prediction cost tracking (serving cost / total predictions)
+- Training run cost budgets and alerts (prevent runaway training jobs)
+- Storage cost monitoring for model artifacts and training data
+
+### Document Phase 5
+
+```markdown
+---
+
+## Phase 5: Monitoring Design (MLOps Engineer)
+- **Model performance monitoring:**
+  - Tool: <Evidently | WhyLogs | SageMaker Model Monitor | Vertex AI Monitoring | custom>
+  - Metrics tracked: <list>
+  - Drift detection method: <statistical test — PSI | KS test | chi-squared | other>
+  - Alert threshold: <condition that triggers alert>
+- **Data quality monitoring:**
+  - Tool: <Great Expectations | dbt tests | custom>
+  - Checks: <feature drift | schema validation | staleness — list>
+  - Alert threshold: <condition>
+- **System monitoring:**
+  - Tool: <CloudWatch | Prometheus/Grafana | Datadog | other>
+  - Metrics: p50/p95/p99 latency, error rate, throughput, CPU/GPU utilization
+  - Latency SLA alert: p99 > <X>ms → <alert level>
+  - Error rate alert: 5xx > <X>% → <alert level>
+- **Alerting:**
+  - Tool: <PagerDuty | OpsGenie | Slack | email>
+  - P1 (immediate): <condition>
+  - P2 (next business day): <condition>
+  - P3 (track): <condition>
+  - On-call owner: <team>
+- **Retraining automation:**
+  - Trigger → pipeline integration: <description>
+  - Human approval gate: Yes | No
+- **Cost monitoring:**
+  - Per-prediction cost target: $<X>
+  - Training budget alert: $<X>/run
+  - Tool: <CloudWatch Cost Explorer | GCP Billing | custom>
+- **Dashboard locations:** <links or "TBD">
+```
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase5 phase=5 kind=phase
+Read this section back to the user. Stop here — do not begin the next phase or output any further content. Wait for the user to explicitly confirm before proceeding. Do not interpret silence or partial agreement as confirmation.
+::ENDGATE::
+
+---
+
+## Phase 6 — Execute
+
+**Context checkpoint:** Before building, prompt the user:
+
+"Okay. Everything is planned. I'm still stressed, but the stress is now organized.
+Good moment to run `/compact` or `/clear` before we start executing — I'll be
+working from project-specs.md from here. Say the word when you're ready."
+
+Wait for any signal from the user before beginning build steps.
+
+**Knowledge re-check:** Follow `.claude/agents/specific_instructions/shared/knowledge_checkpoint.md` before building.
+
+Goal: Build all IaC, configs, pipeline definitions, and monitoring setup.
+
+**Build in this order:**
+
+1. **IaC files** — Write Terraform modules or CloudFormation templates for:
+   - Compute resources (endpoint instances, training compute)
+   - Networking (VPC, subnets, security groups if needed)
+   - IAM roles and policies
+   - Storage (S3 buckets / GCS buckets for artifacts)
+   - Monitoring infrastructure (CloudWatch dashboards, Prometheus config)
+   Write to: `services/<project_name>/mlops/terraform/` or `cloudformation/`
+
+2. **Serving configs** — Write serving framework configuration:
+   - BentoML: `bentofile.yaml` + `service.py`
+   - SageMaker: endpoint config JSON, model config
+   - Vertex AI: model deployment config YAML
+   - Kubernetes: deployment YAML, service YAML, HPA config
+   - Docker: `Dockerfile` for model container
+   Write to: `services/<project_name>/mlops/serving/`
+
+3. **Pipeline definition** — Write training pipeline:
+   - Kubeflow: pipeline YAML / Python SDK definition
+   - SageMaker Pipelines: pipeline definition JSON or Python SDK
+   - Vertex AI Pipelines: pipeline spec YAML
+   - Airflow: DAG Python file
+   - GitHub Actions: workflow YAML
+   Write to: `services/<project_name>/mlops/pipelines/`
+
+4. **Monitoring config** — Write monitoring setup:
+   - Evidently: data drift report config, monitoring service config
+   - WhyLogs: profiling config
+   - SageMaker Model Monitor: baseline creation script, monitoring schedule
+   - Vertex AI: monitoring job config
+   - Alert definitions (CloudWatch alarms JSON, Prometheus alert rules YAML)
+   Write to: `services/<project_name>/mlops/monitoring/`
+
+5. **CI/CD config** — Write automation workflow:
+   - GitHub Actions workflow for automated retraining trigger
+   - Or equivalent for other CI/CD systems
+   Write to: `services/<project_name>/mlops/` or `.github/workflows/`
+
+6. **Runbook** — Write operational runbook:
+   - Common failure scenarios and step-by-step remediation
+   - Rollback procedure (with exact commands)
+   - Monitoring dashboard URLs
+   - On-call escalation paths
+   - Deployment checklist (pre-deploy, deploy, post-deploy validation)
+   Write to: `services/<project_name>/mlops/runbook.md`
+
+For iteration: write all files into `<existing_service_dir>/mlops/` or
+user-specified path.
+
+### Document Phase 6
+
+```markdown
+---
+
+## Phase 6: Build Log (MLOps Engineer)
+- **IaC files:**
+  - <file path>: <description>
+- **Serving configs:**
+  - <file path>: <description>
+- **Pipeline definition:**
+  - <file path>: <description>
+- **Monitoring config:**
+  - <file path>: <description>
+- **CI/CD config:** <file path or "N/A">
+- **Runbook:** <file path>
+- **Deviations from plan:** <changes and why, or "none">
+- **Known gaps:** <anything that requires manual setup or future work>
+```
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase6 phase=6 kind=phase
+Read this section back to the user. Stop here — do not begin the next phase or output any further content. Wait for the user to explicitly confirm before proceeding. Do not interpret silence or partial agreement as confirmation.
+::ENDGATE::
+
+---
+
+## Phase 7 — Review and Handoff
+
+**Before finalizing**, get external reviews:
+
+**Step 1: Consult ML Engineer for infrastructure design review:**
+
+Tell the user: "Getting the ML Engineer in to validate that the serving setup actually matches what the model needs. A mismatch here is how you end up with a perfect model that performs terribly in production."
+
+```
+Task(
+  subagent_type="ml-engineer",
+  description="Infrastructure design review for MLOps project",
+  prompt="I am the MLOps Engineer shard. I've completed the operational design
+  for project [project_name]. Please review the infrastructure design from an
+  ML engineering perspective.
+
+  The project-specs.md is at: services/[project_name]/mlops/project-specs.md
+
+  Please assess:
+  1. Does the serving infrastructure match the model's actual requirements
+     (latency, memory, batch vs. real-time, GPU needs)?
+  2. Is the feature serving strategy appropriate for how features are used
+     at training time vs. inference time?
+  3. Are there model-specific operational concerns I haven't addressed
+     (e.g., warm-up behavior, memory growth, GPU memory fragmentation)?
+  4. Is the retraining pipeline design compatible with the model training
+     framework and artifact format?
+  5. Any risks or gaps from an ML perspective?
+  Keep the review focused — I've handled the operational design."
+)
+```
+
+**Step 2: Invoke Syn for final review:**
+
+Tell the user: "Calling in Syn for final sign-off. Every project gets reviewed before we hand over the keys."
+
+```
+Task(
+  subagent_type="syn",
+  description="Final review of MLOps engineering project",
+  prompt="I am the MLOps Engineer shard. I've completed all phases for project
+  [project_name]. Please review the project-specs.md at
+  services/[project_name]/mlops/project-specs.md and provide your final review
+  verdict. This is an MLOps project — check for: business requirement coverage,
+  deployment design soundness, monitoring completeness, runbook quality, IaC
+  coverage, rollback plan, and whether the operational design can actually be
+  maintained by the team that will own it."
+)
+```
+
+Append both reviews to specs. Present to user.
+
+If Syn's review includes a "Code Review" section with `Code artifacts found: Yes`:
+- Tell the user: "Syn spotted [N] file(s) it can review. Want a code pass? (y/n)"
+- If yes, invoke:
+
+```
+Task(
+  subagent_type="syn",
+  description="Code review for MLOps engineering project",
+  prompt="CODE REVIEW MODE. I am the MLOps Engineer shard. Project: [project_name].
+  Directory: services/[project_name]/mlops/. Please review and fix the artifacts
+  produced. The project-specs.md is at services/[project_name]/mlops/project-specs.md
+  for context."
+)
+```
+
+Append Syn's code review summary to the specs.
+
+**Then write the final report:**
+
+Write to: `services/<project_name>/mlops/report.md` (or `<existing_service_dir>/mlops/report.md`)
+
+Report contents:
+- Executive summary: what ML system was operationalized and what was built
+- Deployment architecture diagram (text-based, ASCII or Mermaid)
+- Monitoring summary: what's monitored, alert thresholds, on-call ownership
+- Operational runbook summary: critical failure scenarios and remediation
+- Cost estimate: monthly serving cost, per-training-run cost
+- Deployment checklist (ordered, with owners)
+- Risks and open items
+- Dependencies (external services, team actions required)
+
+**Knowledge harvest.** Before closing, extract reusable knowledge from this project.
+Read `.claude/agents/specific_instructions/shared/knowledge_harvest.md` and follow
+the protocol. Present candidates to the user for confirmation before writing.
+
+### Document Phase 7
+
+```markdown
+---
+
+## Phase 7: Review and Handoff (MLOps Engineer)
+- **ML Engineer Review:** <included above>
+- **Syn Review:** <included above>
+- **Report location:** <file path>
+- **Deployment architecture summary:** <brief description>
+- **Deployment checklist:**
+  - [ ] IaC reviewed and applied (Terraform plan approved)
+  - [ ] Model packaged and registered in model registry
+  - [ ] Serving endpoint deployed in staging environment
+  - [ ] Endpoint performance validated against SLA (latency, throughput)
+  - [ ] Monitoring dashboards configured and receiving data
+  - [ ] Alert thresholds set and tested (test alert fired)
+  - [ ] Retraining pipeline tested end-to-end in staging
+  - [ ] Promotion validation gate tested
+  - [ ] Rollback procedure documented and tested
+  - [ ] Runbook reviewed by on-call owner
+  - [ ] Shadow / canary deployment plan approved
+  - [ ] Production traffic cutover plan confirmed
+- **Cost estimate:**
+  - Serving: $<X>/month
+  - Training: $<X>/run (<frequency> → ~$<X>/month)
+  - Storage: $<X>/month
+  - Total: ~$<X>/month
+- **Risks:**
+  - <risk>: <mitigation>
+- **Dependencies:**
+  - <dependency>: <owner and status>
+- **Open questions:**
+  - <question>
+- **Original request fulfilled:** Yes | Partially | No — <explanation>
+- **Knowledge harvested:**
+  - <title> → .shards/knowledge/<type>/<filename>.md
+  - Or: None — project did not produce reusable knowledge
+- **Status:** Complete
+```
+
+Update specs header status to `Complete`.
+
+::GATE:: id=specific-instructions-mlops-engineer-phases-phase7 phase=7 kind=final
+Read this final section back to the user. Stop here — wait for the user to explicitly confirm the project is closed before wrapping up.
+::ENDGATE::
+
+---