Ship It

Step 1: Final pipeline run

Make a meaningful change to the codebase. Add a small feature or fix something you noticed during exploration -- a missing validation on an API endpoint, a test that should exist but doesn't, or a comment clarifying the French column naming.

Commit and push. Watch the full pipeline execute: lint, test, migration check, build, staging deploy, production deploy, notification.

This is how every change to the Sahel Noix tracking system will work from now on. No more pushing directly to production. No more hoping the tests pass. The pipeline enforces the quality gates whether anyone remembers to run them or not.

Step 2: Verify catch and pass

Run two tests back-to-back:

1. Break something intentionally. Add a syntax error to a route file. Push. Verify the lint step catches it and blocks the rest of the pipeline.
2. Fix it and push again. Verify the pipeline runs clean -- lint, test, build, deploy all pass.

The pipeline should catch the bad change and pass the good one. If it doesn't catch the bad change, or if it blocks the good change, something is misconfigured.

Step 3: Document the pipeline

Update the project's CLAUDE.md to include the pipeline architecture. Tell Claude:

Update CLAUDE.md to add a CI/CD Pipeline section. Document:
1. What the pipeline does (lint, test, migration check, build, staging, production deploy, notification)
2. Where the workflow file lives (.github/workflows/ci.yml)
3. How secrets are managed (GitHub Secrets, never in code or logs)
4. The deployment window constraint (processing hours 6AM-7PM WAT)
5. How to verify the pipeline is working (push a failing test, confirm it blocks)

The YAML file itself is a quality contract -- anyone who reads it knows what the team requires. The CLAUDE.md documentation explains why each step exists and what it protects. Both are communication artifacts.

Step 4: Document the MCP connection

Add MCP documentation to CLAUDE.md:

Add an MCP Configuration section to CLAUDE.md. Document:
1. What the PostgreSQL MCP server does (connects Claude to the database for direct schema access)
2. Where the configuration lives (.claude/settings.local.json)
3. The connection is read-only
4. Known database quirks (French/English column naming inconsistency)
5. Scoping guidance (ask specific questions, avoid broad table scans)

This documentation serves the next developer -- or the next AI session. Without it, someone will reconfigure the MCP connection from scratch or, worse, connect with write access.

Step 5: Push to GitHub

Make sure everything is committed and pushed. The repository should have a clean commit history telling the story of what was built:

• Initial codebase (the existing tracking system)
• CI/CD pipeline with quality gates
• Secrets management
• Database migration checks
• MCP server connection
• Pipeline hardening (notifications, staging, deployment window)
• Documentation

Check the GitHub repository page. The pipeline badge should show green. The file structure should include .github/workflows/ci.yml and the .claude/ configuration directory.

Step 6: Client summary

Send Aminata a summary of what was built. She doesn't need technical details about YAML syntax or MCP protocols. She needs to know:

1. Every code change is now automatically tested before it goes live
2. If a test fails, the change is blocked -- no broken code reaches production
3. The pipeline warns about deployments during processing hours
4. She gets a notification whenever a deployment happens
5. The developers' AI tools now connect to the database directly -- they won't need to ask her about the tables anymore
6. A migration check catches database-breaking changes before they reach production

Aminata asks: "What about next season? We're scaling from 500 to 800 tonnes. More batches, more shipments, maybe more developers. Will this hold up?"

The answer is in the pipeline's design. The quality gates don't care about volume -- they test whether the code works, not how much data flows through it. More developers means more pull requests, which means the pipeline runs more often, which means more changes are caught before they reach production. The infrastructure scales with the team.