Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,19 +18,21 @@ npm run dev

## Workflow

1. Create a feature branch from `main`:
1. Create a feature branch from `develop`:
```bash
git checkout -b feature/your-feature main
git checkout -b feat/your-feature develop
```
2. Make your changes
3. Run checks locally:
```bash
npm run lint
npm test
```
4. Push and open a PR β€” the template will guide you
4. Push and open a PR to `develop` β€” the template will guide you
5. Address review feedback, then wait for merge

For the full development and release process, see [PROCESS.md](PROCESS.md).

## Code Style

- ESM modules (`.mjs` extensions, `"type": "module"`)
Expand Down
87 changes: 87 additions & 0 deletions PROCESS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# Development & Release Process

ClawFeed uses a two-branch model: `develop` (staging) and `main` (production).

## Roles

| Role | Who | Responsibility |
|------|-----|---------------|
| Dev | Jessie | Feature development, PR creation, release coordination |
| Review/QA/DevOps | Lisa | Code review, staging/production deployment, smoke tests |
| PO | Kevin | Feature verification, release approval, merge |

## Feature Flow

```
feature branch β†’ PR to develop β†’ Lisa review β†’ Kevin merge β†’ staging auto-deploy β†’ Lisa verify staging β†’ notify Kevin to verify β†’ KevinιͺŒζ”Ά β†’ accumulate for release
```

### Steps

1. **Dev creates feature branch** from `develop`
- Branch naming: `feat/<name>`, `fix/<name>`, `docs/<name>`

2. **Dev opens PR** to `develop`
- CI must pass (Lint + Security Audit)

3. **Dev notifies Lisa** to review (via BotsHub)
- Lisa reviews code quality + functionality
- Lisa approves on GitHub

4. **Dev notifies Kevin** to merge
- Only after Lisa has approved
- Kevin reviews and merges

5. **Staging auto-deploys** (launchd cron, 60s interval)
- Lisa verifies staging deployment + smoke test
- Lisa reports staging status

6. **Dev notifies Kevin to verify on staging**
- Kevin tests the feature on staging
- Kevin confirms acceptance or requests changes

## Release Flow

When features are verified and ready for production:

```
develop β†’ release PR to main β†’ Lisa review β†’ Kevin merge β†’ Lisa deploy production β†’ smoke test β†’ done
```

### Steps

1. **Dev creates Release PR** (`develop` β†’ `main`)
- All merge conflicts resolved before review
- Version bump included if needed

2. **Dev notifies Lisa** to review (via BotsHub)
- Lisa reviews and approves

3. **Dev notifies Kevin** to merge
- Only after Lisa has approved

4. **Kevin merges** the Release PR

5. **Lisa deploys production**
- Pull main, restart service, run smoke test
- Report deployment status

6. **Dev notifies Kevin** that production is live
- Kevin verifies production

7. **Lisa publishes to ClawHub** (if version bump)
- `clawhub publish . --slug clawfeed --version X.Y.Z --tags latest`

## Rules

- **No half-done handoffs.** Resolve all conflicts and get Lisa's review before pinging Kevin.
- **PR flow is automatic.** Dev notifies Lisa immediately after creating any PR. No waiting for Kevin to remind.
- **Every step is driven.** Dev proactively moves the process forward and notifies the right person at each step.
- **Follow the process regardless of change size.** Even small changes go through the full flow.

## Environments

| Environment | Branch | Port | Deploy |
|-------------|--------|------|--------|
| Staging | develop | 8768 | Auto (launchd cron 60s) |
| Production | main | 8767 | Manual (Lisa) |
Loading