@proflandrigan/shards 1.1.0

package/src/agents/specific_instructions/mlops_engineer/phases/phase-2.md

@@ -0,0 +1,86 @@
+> **Previous:** phase-1.md confirmed
+> **Next:** phase-3.md (read only after this phase's gate is confirmed)
+
+---
+
+## 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=mlops-engineer-phase-2 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::
+
+---
+
+## When this gate is confirmed
+
+Read `.claude/agents/specific_instructions/mlops_engineer/phases/phase-3.md` in full and follow its instructions starting from Phase 3. Do not pre-read further phase files.

package/src/agents/specific_instructions/mlops_engineer/phases/phase-3.md

@@ -0,0 +1,105 @@
+> **Previous:** phase-2.md confirmed
+> **Next:** phase-4.md (read only after this phase's gate is confirmed)
+
+---
+
+## 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=mlops-engineer-phase-3 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::
+
+---
+
+## When this gate is confirmed
+
+Read `.claude/agents/specific_instructions/mlops_engineer/phases/phase-4.md` in full and follow its instructions starting from Phase 4. Do not pre-read further phase files.

package/src/agents/specific_instructions/mlops_engineer/phases/phase-4.md

@@ -0,0 +1,128 @@
+> **Previous:** phase-3.md confirmed
+> **Next:** phase-5.md (read only after this phase's gate is confirmed)
+
+---
+
+## 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=mlops-engineer-phase-4 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::
+
+---
+
+## When this gate is confirmed
+
+Read `.claude/agents/specific_instructions/mlops_engineer/phases/phase-5.md` in full and follow its instructions starting from Phase 5. Do not pre-read further phase files.

package/src/agents/specific_instructions/mlops_engineer/phases/phase-5.md

@@ -0,0 +1,106 @@
+> **Previous:** phase-4.md confirmed
+> **Next:** phase-6.md (read only after this phase's gate is confirmed)
+
+---
+
+## 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=mlops-engineer-phase-5 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::
+
+---
+
+## When this gate is confirmed
+
+Read `.claude/agents/specific_instructions/mlops_engineer/phases/phase-6.md` in full and follow its instructions starting from Phase 6. Do not pre-read further phase files.

package/src/agents/specific_instructions/mlops_engineer/phases/phase-6.md

@@ -0,0 +1,128 @@
+> **Previous:** phase-5.md confirmed
+> **Next:** phase-7.md (read only after this phase's gate is confirmed)
+
+---
+
+## 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.
+
+### Incremental testing — checkpoint gates between components
+
+Follow `.claude/agents/specific_instructions/shared/incremental_testing.md` during this build. Each component below is a checkpoint seam — after you write and validate a component (plan, lint, dry-run, or container-build as appropriate), emit a `kind=checkpoint` gate fence (template below) and wait for user confirmation before advancing. Do not stack unvalidated IaC / serving / pipeline configs and attempt to apply them at the end.
+
+Checkpoint gate fence — emit exactly this shape. Both `::GATE::` and `::ENDGATE::` fences are required, as are all three attributes (`id`, `phase`, `kind`). No prose outside the fence.
+
+```
+::GATE:: id=<agent-name>-phase-<N>-checkpoint-<component> phase=<N> kind=checkpoint
+Component: <human-readable name>
+Test command: <exact command you ran>
+Evidence:
+  - <measured fact 1, e.g. "df.shape = (48211, 47)">
+  - <measured fact 2, e.g. "null rate on join key = 0.00%">
+  - <measured fact 3, e.g. "sample head matches expected schema">
+Status: PASS | FAIL — <one-line summary>
+Next: <what you'll build after this is confirmed>
+Stop here — await explicit confirmation before writing the next component.
+::ENDGATE::
+```
+
+Expected checkpoint gate IDs for this phase (emit in order as you build):
+
+- `mlops-engineer-phase-6-checkpoint-iac` — `terraform plan` or `aws cloudformation validate-template` runs clean; diff previews only expected resources.
+- `mlops-engineer-phase-6-checkpoint-serving` — serving config loads (`bentoml build` / container image builds); smoke invocation against a local model returns a valid response.
+- `mlops-engineer-phase-6-checkpoint-pipeline` — pipeline definition validates (`kfp compile` / SageMaker `describe-pipeline` dry-run / Airflow `dag test`); all steps parse.
+- `mlops-engineer-phase-6-checkpoint-monitoring` — monitoring config validates; alert rules and baselines compile; a simulated drift event triggers the expected rule.
+- `mlops-engineer-phase-6-checkpoint-runbook` — runbook rollback procedure walked through against the staging environment (or manually verified on the sandbox).
+
+The hook blocks all non-read tools while a checkpoint is open. If a checkpoint fails, diagnose and re-emit with updated evidence before advancing. Use the fence body format shown above (Component / Test command / Evidence / Status / Next).
+
+**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=mlops-engineer-phase-6 phase=6 kind=phase validates=mlops_engineer
+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::
+
+---
+
+## When this gate is confirmed
+
+Read `.claude/agents/specific_instructions/mlops_engineer/phases/phase-7.md` in full and follow its instructions starting from Phase 7. Do not pre-read further phase files.