# Development Workflow

A snapshot of how AI Systems and the Development team currently work together. This is the current state, documented for clarity and SOC 2 compliance. It will be iterated on as the relationship matures.

***

## The People

| Role                    | Person  | Function                                                                                                                                |
| ----------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| CEO                     | Brianne | Assigns AI work via Asana tasks.                                                                                                        |
| CSO                     | Tim     | Provides strategy and technical input. Sits between AI Systems and Development and represents both sides in the weekly Development L10. |
| AI Systems Architect    | Ryan    | Builds AI tools, apps, and automations.                                                                                                 |
| Director of Engineering | Rayford | Owns The Mailworks GitHub, code review, QA, and production deployment.                                                                  |

***

## Coordination

* **Work comes in** via Asana tasks from Brianne.
* **Strategy and technical direction** are shaped with Tim.
* **Day-to-day AI and Development coordination** flows through Tim, who meets with Rayford in a weekly Development L10.
* **Ryan contributes to Asana tasks** with updates and comments as work progresses.
* There is no direct recurring sync between AI Systems and Development today. Tim is the connective tissue.

***

## Boundaries

What AI Systems works on falls into two categories, and the category determines whether Development is involved.

### Autonomous (No Dev Handoff)

Anything that lives inside Claude and does not deploy anywhere.

* Cowork automations running on a local machine
* Claude Code tasks
* Skills, prompts, and configuration inside Claude Enterprise
* Anything that only affects internal AI workflows

AI Systems has full autonomy here. No dev review, no handoff.

### Dev Process Required

Anything that becomes an app, a repo, runs on Mailworks infrastructure, or touches Mailworks production systems and databases.

* Internal apps and tools
* Automations that run server-side or on Mailworks infrastructure
* Anything integrated with Portal, production databases, or other business-critical systems
* The Mailworks Docs Platform (currently in local development; will follow the dev process when it is ready for handoff)

This category goes through the build and handoff process below.

***

## The Build and Handoff Process

1. **Build and test.** Each tool lives in its own repo. Ryan builds in a personal GitHub repo and conducts user testing until the tool is stable and validated. All app builds use a **staging environment** scaffolded by Development, with test credentials to the necessary databases. This is pre-provisioned so AI Systems never has to request access mid-project. Before handoff, Ryan runs the code through **DeepSource**, **CodeRabbit**, or a comparable tool and does a due-diligence pass to surface and fix issues early and streamline the downstream QA process.
2. **Request transfer.** Tim submits a ticket to Development to initiate the ownership transfer.
3. **Transfer ownership.** The repo is transferred to The Mailworks GitHub organization (administered by Rayford) and merged into a staging or dev branch. Development adds Ryan as a collaborator on the transferred repo so he can submit pull requests to iterate if needed. Once ownership is transferred, Development is responsible for connecting the repo to the live production environment.
4. **Automated checks.** The Mailworks GitHub runs **DeepSource** for bugs and security vulnerabilities, and **ESLint** (via `pnpm run lint`) for code quality and formatting.
5. **Human review and QA.** Once automated checks pass, the Development team performs code review and QA testing. This is the security review of record.
6. **Production.** After QA passes, the code is merged into production.
7. **Post-deployment ownership.** Once live, the Development team owns ongoing maintenance. Junior developers handle bug fixes, upkeep, and addressing any security vulnerabilities in dependencies. Users report bugs directly to Development.

***

## Governance

* **Security review:** DeepSource plus Development team code review and QA constitute the security review before production.
* **Access grants:** Rayford grants access to repos, infrastructure, and production environments up front, so AI Systems does not need to request access mid-project.
* **Compliance posture:** This process exists to support SOC 2 compliance. The operating principle is *move fast, stay safe and compliant.*

***

## Known Gaps and Open Questions

* No direct recurring sync between AI Systems and Development.
* The edge between "autonomous" and "dev process" will need clearer criteria as automations grow in scope and reach.

These will be worked out as the process matures.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://knowledge.themailworks.com/how-we-work/development-workflow.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
