oneie/one/things/plans/development-workflow.md

Build apps, websites, and AI agents in English. Zero-interaction setup for AI agents (Claude Code, Cursor, Windsurf). Download to your computer, run in the cloud, deploy to the edge. Open source and free forever.

---
title: Development Workflow
dimension: things
category: plans
tags: ai, architecture, backend
related_dimensions: events
scope: global
created: 2025-11-03
updated: 2025-11-03
version: 1.0.0
ai_context: |
  This document is part of the things dimension in the plans category.
  Location: one/things/plans/development-workflow.md
  Purpose: Documents development workflow: managing /web and /oneie
  Related dimensions: events
  For AI agents: Read this to understand development workflow.
---

# Development Workflow: Managing /web and /oneie

**Status:** Cycle 46 - Active Development
**Version:** 2.0.0 (CORRECTED - CRITICAL UPDATE)
**Last Updated:** 2025-10-29

---

## The CORRECT Architecture (Two-Site Flow)

**This is NOT what I said before.** Your architecture has a **one-way generation flow**:

```
ONE Platform (Root)
│
├── /oneie/                    ← EDIT HERE - Production site (one.ie)
│   ├── .git                   ← Separate repo (one-ie/oneie) - AUTHORITATIVE
│   ├── package.json
│   └── scripts/generate-starter.sh  ← Generates /web from /oneie
│
├── /web/                      ← AUTO-GENERATED FROM /oneie
│   ├── .git                   ← Separate repo (one-ie/web)
│   └── package.json
│   └── ⚠️  DO NOT EDIT - Regenerated by: bun run build:starter
│
├── /backend/                  ← Convex backend (shared)
│   └── .git (one-ie/backend)
│
├── /cli/                      ← npm CLI tool
│   └── .git (one-ie/cli)
│
├── /one/                      ← Documentation
│   └── .git (one-ie/ontology)
│
└── /apps/                     ← Assembly repos (copies)
    ├── /apps/oneie/          ← Synced from /oneie and /one
    └── /apps/one/            ← Synced from /oneie and /one
```

### The Critical Difference

- **OLD (Wrong):** `/web` and `/oneie` are independent
- **CORRECT (Real):** `/web` is **generated from `/oneie`**

Your source of truth is **`/oneie/`**. Everything flows from there.

---

---

## The Correct Workflow (Two-Site Architecture)

### The One-Way Generation Flow

```
EDIT HERE (Always)           GENERATED              DEPLOYED
    ↓                           ↓                      ↓
/oneie/          →   bun run build:starter   →   /web/
(Edit & Commit)      (Generate starter)         (Auto-generated)

                     git add . && commit
                            ↓
                    /apps/oneie/ & /apps/one/
                    (Assembly repos)
                            ↓
                    Cloudflare Pages (Deployed)
```

### Critical Rule

**ONLY edit `/oneie/`. NEVER edit `/web/` directly.**

`/web/` is auto-generated from `/oneie/` and will be overwritten.

---

## Development Scenarios

### Scenario 1: Developing Features in `/oneie` (Most Common)

**What:** Building one.ie - the production website
**When:** New features, bug fixes, content updates, anything production
**Flow:** Edit → Test → Generate → Commit → Deploy

```bash
# 1. Navigate to /oneie (the source of truth)
cd /Users/toc/Server/ONE/oneie

# 2. Start dev server (localhost:4321)
bun run dev

# 3. Edit files
# src/pages/
# src/components/
# src/layouts/
# content/
# etc.

# 4. Test locally
# Visit http://localhost:4321
# Test all changes

# 5. Commit changes to /oneie
git add .
git commit -m "feat: add new feature"
git push origin main

# 6. Generate /web from /oneie
cd /Users/toc/Server/ONE/oneie
bun run build:starter

# 7. Commit the auto-generated /web
cd /Users/toc/Server/ONE/web
git add .
git commit -m "chore: regenerate starter from oneie

⚠️  AUTO-GENERATED. Do not edit directly."
git push origin main

# 8. Deploy both sites
cd /Users/toc/Server/ONE/oneie
bun run deploy

cd /Users/toc/Server/ONE/web
bun run deploy
```

**What `bun run build:starter` does:**

- Copies `/oneie/src` → `/web/src`
- Replaces homepage with template chooser
- Simplifies sidebar (2 items only)
- Reduces content (1 blog post, 3 products)
- Updates package.json name to "oneie-starter"

**Key Points:**

- `/oneie/` is the **authoritative source**
- `/web/` is **generated** from `/oneie/`
- Both have their own Git repos and deployments
- Changes in `/oneie/` automatically flow to `/web/`
- Changes in `/web/` will be OVERWRITTEN next time you generate

**Don't do:**

- ❌ Edit `/web/` directly (will be overwritten)
- ❌ Edit `/apps/oneie/` (it's a copy for assembly)
- ❌ Commit changes in `/web/` before generating (they get lost)
- ❌ Skip the `bun run build:starter` step

---

### Scenario 2: The Complete Release Flow

**When:** You're ready to release a new version

```bash
# 1. Make sure /oneie is committed and on main
cd /Users/toc/Server/ONE/oneie
git status  # Should be clean

# 2. Generate starter template from /oneie
bun run build:starter

# 3. Commit /web changes
cd ../web
git add .
git commit -m "chore: regenerate starter from oneie

⚠️  AUTO-GENERATED. Do not edit directly."
git push origin main

# 4. Deploy both
cd ../oneie
bun run deploy

cd ../web
bun run deploy

# 5. Optional: Push to assembly repos and bump version
cd /Users/toc/Server/ONE
./scripts/release.sh patch   # or minor/major
```

**Flow:**

1. Edit `/oneie/`
2. Run `bun run build:starter` to generate `/web/`
3. Commit both
4. Deploy both
5. Run release script for version management

---

### Scenario 3: What NOT to Do

#### ❌ DON'T Edit `/web/` Directly

```bash
# WRONG - These changes will be lost!
cd /web
vim src/pages/index.astro
git add . && git commit -m "changes"

# Then someone runs:
cd ../oneie
bun run build:starter

# Result: Your /web changes are OVERWRITTEN
```

**Why?** `/web/` is auto-generated. The generator will replace it.

#### ❌ DON'T Skip Generate

```bash
# WRONG - web/ will be out of sync
cd oneie
# ... make changes
git commit -m "feat: changes"

cd ../web
git commit -m "some changes"
git push origin main

# Your /web is now DIFFERENT from /oneie!
```

**Why?** You need to run `bun run build:starter` to sync them.

#### ❌ DON'T Deploy /web Without Regenerating

```bash
# WRONG - web will be out of date
cd oneie
# ... make changes
git commit -m "feat: changes"
bun run deploy

# /oneie updated but /web still has old code!
```

**Why?** You need to regenerate `/web/` first.

---

## The Solution: Development Workflow

### Rule 1: Where to Edit (Choose ONE Pattern)

#### **PATTERN A: Direct Development (RECOMMENDED)**

Use this when developing features for **production-ready** `/web`

```bash
# 1. Edit files directly in /web
cd /web
# ... edit src/components, src/pages, etc.

# 2. Test locally
bun run dev              # Local dev server on localhost:4321
bun test                 # Run tests
bunx astro check         # Type check

# 3. Commit to /web repository
cd /web
git add .
git commit -m "feat: add user authentication UI"
git push origin main

# 4. Run release to sync everywhere
cd /Users/toc/Server/ONE
./scripts/release.sh sync  # Syncs /web to /apps/oneie/web and /apps/one/web

# 5. Deploy
./scripts/release.sh patch  # Or minor/major (includes deployment)
```

#### **PATTERN B: Branch Development (For Complex Features)**

Use this when developing **experimental features** that shouldn't break production yet

```bash
# 1. Create feature branch in /web
cd /web
git checkout -b feature/new-dashboard
# ... edit and test

# 2. Test thoroughly
bun run dev
bun test
bunx astro check

# 3. Keep local OR merge to main when ready
git checkout main
git merge feature/new-dashboard
git push origin main

# 4. Then run release sync
cd /Users/toc/Server/ONE
./scripts/release.sh sync
```

#### **PATTERN C: Temporary Edits (For Quick Fixes)**

Use this when fixing **urgent bugs** that need immediate testing

```bash
# 1. Quick edit in /web (no branch)
cd /web
# ... fix bug in src/components/SomeComponent.tsx

# 2. Test
bun run dev

# 3. Don't forget to commit!
git add .
git commit -m "fix: resolve auth token expiration"
git push origin main

# 4. Sync to deployment targets
cd /Users/toc/Server/ONE
./scripts/release.sh sync
```

---

## Step-by-Step Development Process

### For Every Feature or Bug Fix

```
┌─────────────────────────────────────────────┐
│ 1. Understand                               │
│    Read /one/knowledge/ontology.md          │
│    Check CLAUDE.md for patterns             │
│    Map to 6 dimensions                      │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ 2. Edit /web (Always Source of Truth)       │
│    cd /web                                  │
│    Edit src/pages, src/components, etc.     │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ 3. Test Locally                             │
│    bun run dev          (local server)      │
│    bun test             (unit/integration)  │
│    bunx astro check     (types)             │
│    Test in browser on localhost:4321        │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ 4. Commit to /web                           │
│    git add .                                │
│    git commit -m "feat: description"        │
│    git push origin main                     │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ 5. Sync to Assembly Repos                   │
│    cd /Users/toc/Server/ONE                 │
│    ./scripts/release.sh sync                │
│    (NO version bump, just syncs /web)       │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ 6. Deploy (When Ready for Production)       │
│    ./scripts/release.sh patch               │
│    (Bumps version + syncs + deploys)        │
└─────────────────────────────────────────────┘
```

---

## Command Reference

### Local Development

```bash
# Navigate to web directory
cd /web

# Start dev server (localhost:4321)
bun run dev

# Run tests
bun test
bun test test/auth              # Run specific test suite
bun test --watch                # Watch mode

# Type check without building
bunx astro check

# Format code
bun run format

# Lint code
bun run lint

# Build for production
bun run build

# Clean everything
cd /Users/toc/Server/ONE
bun run clean
```

### Syncing to Deployment Targets

```bash
# From root directory (/Users/toc/Server/ONE)

# Sync WITHOUT version bump (development)
./scripts/release.sh sync

# Sync with version bump (release)
./scripts/release.sh patch      # Bug fixes (1.0.0 → 1.0.1)
./scripts/release.sh minor      # Features (1.0.0 → 1.1.0)
./scripts/release.sh major      # Breaking changes (1.0.0 → 2.0.0)
```

### What Each Release Command Does

```
./scripts/release.sh sync
├── Syncs /web to /apps/oneie/web and /apps/one/web
├── Syncs /one to /apps/oneie/one and /apps/one/one
├── NO version bump
├── NO deployment to Cloudflare
└── Use this for: Development iterations, feature branches

./scripts/release.sh patch
├── Everything above, PLUS:
├── Bumps version (patch increment)
├── Commits to /apps/oneie and /apps/one with tag
├── Builds and deploys to Cloudflare Pages
├── Prompts for npm publish
└── Use this for: Bug fixes, minor updates

./scripts/release.sh minor
├── Everything patch does, PLUS:
├── Version bump is minor increment (new features)
└── Use this for: New features, improvements

./scripts/release.sh major
├── Everything minor does, PLUS:
├── Version bump is major increment (breaking changes)
└── Use this for: Breaking API changes, major refactors
```

---

## The Sync Process Explained

### What Gets Synced (Release.sh)

```
/web/                    → /apps/oneie/web/
                         → /apps/one/web/

/one/                    → /apps/oneie/one/
                         → /apps/one/one/

/backend/                → /apps/oneie/backend/ (optional)
                         → /apps/one/backend/ (optional)

.claude/                 → /cli/.claude/
                         → /apps/oneie/one/.claude/

CLAUDE.md                → /cli/CLAUDE.md
README.md                → /cli/README.md + /apps/oneie/README.md
LICENSE.md               → All targets
web/AGENTS.md            → /cli/AGENTS.md + /apps/oneie/one/AGENTS.md
```

### Excluded Files (Not Synced)

```
.git                     ← Each repo has its own Git history
node_modules/            ← Dependencies installed separately
dist/                    ← Build artifacts regenerated
.astro/                  ← Cache
.wrangler/               ← Cache
.env                     ← Environment-specific
.env.local               ← Environment-specific
.DS_Store                ← System files
*.swp                    ← Editor temp files
```

---

## Common Workflows

### Workflow 1: Quick Bug Fix

```bash
# 1. Fix bug in /web
cd /Users/toc/Server/ONE/web
vim src/components/Button.tsx
# ... fix the bug

# 2. Test
bun run dev
# ... verify fix works on localhost:4321

# 3. Commit
git add .
git commit -m "fix: button not responding to clicks"
git push origin main

# 4. Sync (development) - no release yet
cd /Users/toc/Server/ONE
./scripts/release.sh sync

# 5. Later: when you're ready to release
./scripts/release.sh patch
```

### Workflow 2: New Feature Development

```bash
# 1. Start feature branch
cd /Users/toc/Server/ONE/web
git checkout -b feature/dark-mode

# 2. Develop
# ... edit multiple files
# ... add tests
# ... update documentation

# 3. Test thoroughly
bun run dev
bun test
bunx astro check

# 4. Review changes
git status
git diff src/

# 5. Commit feature
git add .
git commit -m "feat: add dark mode toggle

- Add theme context provider
- Update all components to support dark theme
- Add dark mode toggle in settings
- Add tests for theme switching"

# 6. Merge to main
git checkout main
git merge feature/dark-mode
git push origin main

# 7. Sync everywhere
cd /Users/toc/Server/ONE
./scripts/release.sh sync

# 8. Later: release as minor version
./scripts/release.sh minor
```

### Workflow 3: Complex Refactoring

```bash
# 1. Create refactor branch
cd /Users/toc/Server/ONE/web
git checkout -b refactor/consolidate-auth

# 2. Work in increments - commit frequently
git commit -m "refactor: extract auth logic to service"
git commit -m "refactor: update login component to use service"
git commit -m "refactor: update signup component"
# ... more commits

# 3. Test all auth paths
bun test test/auth

# 4. Verify no regressions
bun run dev
# ... manual testing

# 5. Merge when confident
git checkout main
git merge refactor/consolidate-auth
git push origin main

# 6. Sync and release
cd /Users/toc/Server/ONE
./scripts/release.sh sync
./scripts/release.sh patch  # or minor if it's a feature-adding refactor
```

### Workflow 4: Emergency Production Fix

```bash
# 1. Create hotfix branch from main
cd /Users/toc/Server/ONE/web
git checkout main
git pull origin main
git checkout -b hotfix/critical-auth-bug

# 2. Fix the critical issue
# ... minimal, focused changes only
# ... no refactoring, no cleanup

# 3. Test the fix
bun run dev
bun test test/auth

# 4. Merge back to main
git checkout main
git merge hotfix/critical-auth-bug
git push origin main

# 5. Immediately release
cd /Users/toc/Server/ONE
./scripts/release.sh sync
./scripts/release.sh patch   # Bumps to x.x.1

# 6. Delete hotfix branch
cd web
git branch -d hotfix/critical-auth-bug
```

---

## What NOT to Do

### ❌ Don't Directly Edit `/apps/oneie/web` or `/apps/one/web`

```bash
# WRONG - changes will be lost on next sync
cd /apps/oneie/web
vim src/pages/index.astro  # ← DON'T DO THIS
git add .
git commit -m "fix: something"

# Why? release.sh will rsync over this:
./scripts/release.sh sync   # ← Overwrites your changes!
```

**Why?** The `release.sh` sync process uses `rsync --delete`, which completely replaces those directories with `/web`.

### ❌ Don't Skip the Commit Step

```bash
# WRONG - only local, not in Git
cd /web
vim src/pages/index.astro
bun run dev  # ← Test works locally

# Then run:
./scripts/release.sh sync   # ← Won't sync your changes to apps/!

# Why? Release.sh syncs the committed Git state of /web
```

**Why?** The release script syncs `/web/` directory, but relies on Git for version history.

### ❌ Don't Edit `/one` Documentation Without Plan

```bash
# WRONG - breaks manual release sync
vim /one/knowledge/ontology.md
./scripts/release.sh sync

# These get overwritten by any conflicting changes
```

**Why?** Documentation should be updated as part of planned releases, not ad-hoc.

### ❌ Don't Run Multiple Release Commands in Succession

```bash
# WRONG - can cause duplicate commits
./scripts/release.sh sync
./scripts/release.sh sync    # ← Redundant
```

**Why?** Each command performs full sync and commits. Running twice = double commits.

---

## Troubleshooting

### Problem: I edited `/web` but changes didn't sync to `/apps/oneie/web`

**Solution:**

1. Verify you committed in `/web`: `cd /web && git log`
2. Verify you pushed: `cd /web && git status` (should be clean)
3. Run sync: `cd /Users/toc/Server/ONE && ./scripts/release.sh sync`

### Problem: My `/apps/oneie/web` edits disappeared after `release.sh sync`

**Solution:**
This is expected! `/apps/*/web/` are auto-generated. Always edit `/web/` instead:

```bash
# Recover from /web (source of truth)
cd /Users/toc/Server/ONE
./scripts/release.sh sync   # Re-sync from /web

# Or manually copy
cp -r /web/ /apps/oneie/web/
```

### Problem: `release.sh sync` failed with "rsync: command not found"

**Solution:**
Install rsync:

```bash
# macOS
brew install rsync

# Linux
sudo apt-get install rsync
```

### Problem: Changes in `/web` are committed but `release.sh` doesn't see them

**Solution:**

1. Check Git status: `cd /web && git status`
2. Make sure branches are up to date: `cd /web && git pull origin main`
3. Verify HEAD: `cd /web && git log -1`
4. Run sync from root: `cd /Users/toc/Server/ONE && ./scripts/release.sh sync`

---

## Decision Tree: Where Should I Edit?

```
What are you developing?
│
├─ Building one.ie (production site)
│  └─ Edit /oneie/ directly
│     └─ cd /oneie && bun run dev
│     └─ bun run deploy (direct deployment)
│     └─ Independent from /web and /apps/
│
├─ Building a reusable starter template
│  └─ Edit /web/ directly
│     └─ cd /web && bun run dev
│     └─ ./scripts/release.sh sync (sync to /apps/oneie/web and /apps/one/web)
│     └─ Independent from /oneie
│
├─ Improving both /web and /oneie
│  └─ Edit both separately:
│     ├─ Apply changes to /web
│     ├─ ./scripts/release.sh sync (syncs /web to /apps/)
│     └─ Manually copy /web changes to /oneie if needed
│
└─ Not editing Astro apps?
   ├─ Updating /backend?
   │  └─ Edit /backend → See backend/AGENTS.md
   │
   ├─ Updating /one documentation?
   │  └─ Edit /one → ./scripts/release.sh sync
   │
   └─ Updating /cli?
      └─ Edit /cli → ./scripts/release.sh sync
```

---

## Summary Table

| What You're Building    | Edit Where      | Deploy                       | Syncing                     | Examples                                |
| ----------------------- | --------------- | ---------------------------- | --------------------------- | --------------------------------------- |
| **one.ie (Production)** | `/oneie/`       | `bun run deploy`             | None needed                 | New pages, features, bugs               |
| **Starter Template**    | `/web/`         | `./scripts/release.sh patch` | `./scripts/release.sh sync` | Reusable components, patterns           |
| **Both Simultaneously** | Both separately | Each has own deploy          | Manual copy-paste           | Shared components + production features |
| **Backend Services**    | `/backend/`     | `npx convex deploy`          | Shared by all               | Mutations, queries, auth                |
| **Documentation**       | `/one/`         | Push to `one-ie/ontology`    | `./scripts/release.sh sync` | Ontology, patterns, guides              |
| **CLI Tool**            | `/cli/`         | `npm publish`                | `./scripts/release.sh sync` | oneie CLI commands                      |

---

## Golden Rules

**Rule 1: Two Independent Projects**

- `/oneie/` is independent (one.ie production)
- `/web/` is independent (starter template)
- **Syncing `/web` does NOT affect `/oneie`**

**Rule 2: Edit at the Source**

- Building one.ie? Edit `/oneie/` directly
- Building starter? Edit `/web/` directly
- **Never edit `/apps/*/web/` - it's auto-generated**

**Rule 3: Deployment**

- `/oneie/` deploys directly via `bun run deploy`
- `/web/` deploys via `./scripts/release.sh patch`
- `/backend/` deploys via `npx convex deploy`

**Rule 4: Sharing Code Between Projects**

- Commit to source (`/web/` or `/oneie/`)
- Sync `/web/` with `./scripts/release.sh sync`
- Manually copy between `/web/` and `/oneie/` as needed
- Don't expect automatic syncing between them

**Rule 5: Never Break the Flow**

- Always commit before running release scripts
- Always push to origin before syncing
- Always test locally before deploying
- Always understand which project you're modifying

---

## Quick Reference Cheatsheet

### Working on one.ie (Production)

```bash
cd /oneie                           # Navigate to project
bun run dev                         # Start local dev (http://localhost:4321)
# ... edit files, test
git add .                           # Commit changes
git commit -m "feat: description"
git push origin main                # Push to one-ie/oneie repo
bun run deploy                      # Deploy to one.ie
```

### Working on /web (Starter Template)

```bash
cd /web                             # Navigate to project
bun run dev                         # Start local dev (http://localhost:4321)
# ... edit files, test
git add .                           # Commit changes
git commit -m "feat: description"
git push origin main                # Push to one-ie/web repo
cd /Users/toc/Server/ONE
./scripts/release.sh sync           # Sync to /apps/oneie/web and /apps/one/web
# Optional: ./scripts/release.sh patch to release version
```

### Updating Backend (Shared)

```bash
cd /backend                         # Navigate to project
# ... edit mutations, queries, schema
git add .
git commit -m "feat: backend changes"
git push origin main                # Push to one-ie/backend repo
npx convex deploy                   # Deploy to Convex Cloud
```

### Updating Documentation

```bash
cd /Users/toc/Server/ONE
# Edit /one/ files
git add .
git commit -m "docs: update ontology"
git push origin main                # Push root repo
./scripts/release.sh sync           # Sync /one to /cli and /apps/
```

### When Confused: Decision Matrix

```
Q: What are you editing?
├─ /oneie/        → Deploy: bun run deploy
├─ /web/          → Deploy: ./scripts/release.sh patch
├─ /backend/      → Deploy: npx convex deploy
├─ /one/          → Deploy: ./scripts/release.sh sync
└─ /cli/          → Deploy: npm publish (after sync)

Q: Will changes affect other projects?
├─ /oneie changes → Only one.ie affected
├─ /web changes   → /apps/oneie/web and /apps/one/web when synced (use ./scripts/release.sh sync)
├─ /backend changes → All projects that use backend
└─ /one changes   → All projects that copy /one

Q: Do I need to sync?
├─ Editing /oneie/        → NO (independent project)
├─ Editing /web/          → YES, if you want changes in /apps/ (./scripts/release.sh sync)
├─ Editing /oneie/ AND /web/ → YES, but only for /web part
└─ Editing /web/ for /oneie  → NO, copy manually instead
```

---

## FAQ

**Q: I edited /oneie, will it sync to /web?**
A: No! `/oneie/` and `/web/` are completely independent. Edit where you want changes.

**Q: I edited /web, but /oneie didn't change!**
A: Correct! You need to manually copy changes or sync to `/apps/` first with `./scripts/release.sh sync`. Syncing only affects `/apps/oneie/web` and `/apps/one/web`, not `/oneie/`.

**Q: Should I edit /apps/oneie/web or /oneie/?**
A: Always edit `/oneie/` - it's the source of truth. `/apps/oneie/web` is a copy that gets overwritten during releases.

**Q: What does `./scripts/release.sh sync` do?**
A: Copies `/web/` → `/apps/oneie/web/` and `/apps/one/web/` (NO version bump, NO deployment to Cloudflare).

**Q: What does `./scripts/release.sh patch` do?**
A: Bumps version + syncs `/web/` + deploys to Cloudflare Pages.

**Q: Can I have /web and /oneie automatically sync?**
A: No. They're intentionally independent. Copy code manually when needed, or use release sync for /web copies only.

**Q: How do I share components between /web and /oneie?**
A: Either:

1. Copy from source to destination manually
2. Use `./scripts/release.sh sync` to copy /web to /apps/ (but this doesn't affect /oneie)
3. Create a shared package in `@oneie/components` and import from both projects

**Q: I made changes in /web and /apps/ but forgot to push. Will release.sh overwrite?**
A: Yes! Always commit and push to Git before running release scripts.

**Q: Can I merge /web and /oneie into one project?**
A: Yes, but you'd lose the separation of concerns:

- `/web/` = reusable for users
- `/oneie/` = production-specific

Better to keep them separate and copy code between them explicitly.

**Q: What if I break the sync process?**
A: Start over:

```bash
cd /Users/toc/Server/ONE
./scripts/release.sh sync  # Re-syncs everything
```

**Q: Do I need to use /apps/ directories?**
A: Only if you're releasing to multiple GitHub repos (`one-ie/oneie`, `one-ie/one`, etc.). For local development, you can ignore them.