🛠️ Professional Dev Workflow (Integrated Tool System)

This guide explains how your installed tools operate as one engineering system, not as isolated apps. The target is a reproducible day-to-day workflow for coding, runtime management, database work, containers, and system operations.

🧠 Core Architecture

Your environment is organized into 5 working layers plus a system foundation:

1) Code Layer

• VS Code (editing, linting, debugging)
• Git (history, collaboration, review)
• pnpm + Corepack (dependency and package-manager consistency)
• Go / Node.js / Godot projects

2) Runtime Layer

• Node.js apps and APIs
• Discord bots (via pnpm dev during development, pm2 for long-running processes)
• Godot runtime/testing from editor

3) Database Layer

• PostgreSQL (local service or Docker container)
• psql (automation, migrations, scripts)
• Beekeeper Studio (inspection, manual exploration)

4) Container Layer

• Docker engine
• Docker Compose v2 (docker compose)
• containerd + runc runtime stack

5) Operations Layer

• tmux (terminal orchestration)
• pm2 (process supervision)
• pacman + yay (system package state)
• journald and package logs for diagnostics

Foundation Tools (Cross-Layer)

• curl, wget: network fetch and endpoint checks
• tar, unzip: archives/tool bootstrap
• base-devel: build toolchain for compiling and AUR packages
• numactl: advanced process memory/CPU binding when needed

🚀 1) Booting Your Development Environment

Step 1: Start infrastructure

If using containers:

docker compose up -d
docker ps

If using system PostgreSQL:

sudo systemctl status postgresql

Step 2: Open control room

Start tmux and keep your workflow in panes/windows:

tmux

Recommended pane layout:

• Pane 1: app runtime (pnpm dev)
• Pane 2: database (psql, migration output, DB checks)
• Pane 3: Git operations and branch management
• Pane 4: bots/scripts/tests/logs

Step 3: Verify package-manager consistency

Use Corepack-managed pnpm to keep version parity:

corepack enable
corepack prepare pnpm@10.33.0 --activate
pnpm install

In projects, pin pnpm version in package.json:

"packageManager": "pnpm@10.33.0"

💻 2) Code Layer Workflow (Git + VS Code + pnpm)

Sync before coding

git fetch --all
git pull --rebase

Start focused branch

git checkout -b feature/<name>

Development loop

pnpm install
pnpm dev
pnpm test

Commit hygiene

git add -p
git commit -m "feat(auth): add login endpoint"

Rules:

• Small commits
• One concern per commit
• Keep main protected and clean

🗄️ 3) Database Layer Workflow (PostgreSQL + psql + Beekeeper)

Use tools by responsibility:

psql = engineering and automation

Use for:

• migrations
• scripts
• repeatable SQL operations
• CI-compatible DB tasks

Example:

psql -U postgres

Beekeeper Studio = visual inspection

Use for:

• browsing schemas/tables
• validating query results
• manual debugging of live data shape

Avoid using it as source-of-truth for production logic changes.

Correct DB change sequence

1. Write migration in code.
2. Apply migration through script/tooling.
3. Verify shape and data in Beekeeper.

If using Prisma:

pnpm prisma migrate dev --name <migration-name>

🐳 4) Container Layer Workflow (Docker Stack)

Common commands:

docker compose up -d
docker ps
docker logs <container-name>

Role boundaries:

• Docker/containerd/runc: infrastructure lifecycle
• pnpm and app scripts: application behavior
• Beekeeper: inspection only

Design principle: containers are disposable. You should be able to recreate services from config.

🤖 5) Runtime Layer (Apps, Bots, Services)

Development runtime

pnpm dev

Long-running managed runtime

pm2 start index.js --name app
pm2 logs app

Use PM2 when you need supervised background processes, restarts, and centralized runtime logs.

🔄 6) Git Collaboration Flow

Branch and push

git checkout -b feature/name
git push origin feature/name

Pull request flow

• Open PR with context and test notes
• Let CI run
• Address review feedback
• Merge only when checks pass

Rebase before merge

git fetch origin
git rebase origin/main

Retest after rebase or conflict resolution.

⚙️ 7) System Operations Integration

Package management policy

• System-level tooling: pacman / yay
• Project dependencies: pnpm
• Runtime isolation: Docker

Useful diagnostics

journalctl -xe
grep "installed" /var/log/pacman.log

For AUR debugging, inspect cache/build state in ~/.cache/yay/.

Package state note

If /etc/pacman.d/mirrorlist.pacnew appears, reconcile it with your active mirrorlist to avoid stale mirror configuration.

📦 8) Installed Program Map (What Each One Is For)

Installed tools you listed, grouped by role:

Core dev and source control

• git: version control and collaboration
• curl, wget: HTTP checks, downloads, automation
• tar, unzip: extraction and packaging tasks
• base-devel: required compile/build tools for native packages/AUR

JavaScript/Node toolchain

• corepack: package manager version control shim
• pnpm (through Corepack): project dependency manager
• pm2: runtime process manager for apps/bots

Database and data tooling

• postgresql: relational database server and CLI tools
• beekeeper-studio-bin: GUI database inspection and querying

Container and runtime stack

• docker: container engine
• Docker Compose v2 (docker compose): multi-service orchestration
• containerd, runc: underlying OCI runtime components

Workflow and system operations

• tmux: persistent multi-pane terminal workspace
• yay, yay-debug: AUR package manager and debugging symbols
• numactl: advanced CPU/memory placement tuning

Language/tooling support

• go: Go development and build toolchain

✅ 9) Daily Professional Sequence

1. Start tmux control room.
2. Bring up services (Docker and/or PostgreSQL).
3. Sync branch state (git fetch --all, git pull --rebase).
4. Install/update dependencies (pnpm install).
5. Run app/bot (pnpm dev) and DB tooling in parallel panes.
6. Implement small scoped change.
7. Run tests and inspect logs.
8. Commit cleanly and push.
9. Open PR and merge after CI + review.

🧭 10) Non-Negotiable Rules

1. Use tmux for serious multi-service work.
2. Database production logic changes go through migrations/scripts, not ad-hoc GUI edits.
3. Beekeeper is for inspection and debugging, not source-of-truth.
4. If work is not committed in Git, it is not part of the system.
5. Containers are disposable and reproducible from configuration.

🧠 Final Mental Model

• VS Code + Git + pnpm/Corepack: engineering brain
• Docker/containerd/runc: environment simulator
• PostgreSQL: system memory
• Beekeeper: microscope
• tmux: control room
• pm2: runtime autopilot

Follow this model consistently and you move from “using tools” to operating a coherent development platform.