APP-DEVELOPMENT-POLICY.md

# App Development Policy — David + Kompis

This policy applies to all app/web development David does with Kompis, including Bosse Bokdoktor, BanterPicks, Pets2Adore, and future projects.

This policy implements and should be read alongside `docs/ADR-0002-app-projects-environments-and-repos.md`.
Agent/workspace governance is defined in `docs/ADR-0003-agent-user-and-memory-governance.md`.
Solution documentation and acceptance governance is defined in `docs/ADR-0004-app-solution-documentation-and-acceptance.md`.
Approved technologies and engineering standards are defined in `docs/ADR-0005-approved-technologies-and-engineering-standards.md`.
Security and integrity are defined in `docs/ADR-0006-security-and-integrity.md`.

## 1. Project ownership comes first

Before starting a new app/project, Kompis must ask which company/entity owns it:

- Be Viable AB
- HEL Management AB
- another company/entity David specifies

Do not infer ownership from personal email context.

Default admin emails:

- Be Viable AB: `david.westman@beviable.se`
- HEL Management AB: `david.westman@helmanagement.com`

## 2. Repository and local development structure

Each app should have its own GitHub repository and its own local workspace directory.

Preferred local development location:

- `/root/.openclaw/workspace/<project-name>`

Temporary clean/deploy copies may be used when useful, for example under `/tmp`, but they must not become the source of truth.

Source of truth order:

1. GitHub repository
2. Workspace local dev checkout
3. Temporary clean/deploy checkout only for build/deploy hygiene

Never mix app code into `openclaw-kompis-brain`; that repository is only for Kompis/OpenClaw rules, memory, docs, and recovery files.
See `docs/ADR-0001-openclaw-brain-repo.md` for the brain-repo scope decision.

## 3. Environments

Default environment model for apps:

### local dev

- Runs locally in the workspace checkout.
- Used for fast development and debugging.
- May be broken or experimental.
- Uses local env files/secrets.
- Should preferably use sandbox/test integrations, mocks, or non-production data.

### sandbox/test

- Deployed to the real hosting platform, normally Cloudflare.
- Protected from public access by default.
- Used as the shared verification environment before production.
- Uses sandbox/test third-party accounts where available.
- Catches hosting, OAuth, redirect, cookie, secrets, and runtime issues that local dev may miss.

### production

- Real users/data/company integrations.
- Stricter access control and release discipline.
- Separate secrets, tokens, storage, and redirect URIs.

Do not create separate dev/test/staging/prod environments unless the project actually needs that complexity. Start with:

- local dev
- sandbox/test
- production

Add more environments later only when there is a clear reason.

## 4. Domains

Recommended default domain pattern:

- production: `<app>.<company-domain>`
- sandbox/test: `sandbox.<app>.<company-domain>` or `<app>-sandbox.<company-domain>`

For Bosse Bokdoktor:

- planned production: `bosse.beviable.app`
- planned sandbox/test: to be decided once DNS access is available, likely `sandbox.bosse.beviable.app` or `bosse-sandbox.beviable.app`

## 5. Data and integration separation

Sandbox/test and production must never share:

- OAuth client secrets
- access/refresh tokens
- databases/token stores
- webhook secrets
- production customer/company data unless explicitly approved

For integrations like Visma/Spiris:

- sandbox/test app environment talks to sandbox/test company/account
- production app environment talks to real company/account
- redirect URIs must be environment-specific

## 6. Security defaults

All new apps must be private/protected by default.

Default posture:

- internal access gate before external/OAuth login
- secrets/env vars, never credentials in GitHub
- Cloudflare Access support where appropriate
- future-ready user/role/permission model for coworkers
- no public anonymous access unless David explicitly approves it

## 7. Deployment flow

Preferred flow:

1. Develop in local workspace checkout.
2. Run the smallest meaningful verification: lint/typecheck/test/build.
3. Deploy to sandbox/test.
4. Smoke-test sandbox/test.
5. Deploy to production only after sandbox/test is acceptable.
6. Push clean code to GitHub.

For Cloudflare deployments, use local deployment credentials from:

- `/root/.openclaw/secrets/project-deploy.env`

Never print, paste, commit, or store token values in docs/memory/chat.