Journey

The setup, told as a progression.

This page follows the setup as it actually came together. Each step exists because I ran into something real, fixed it, and kept going. The point is not to sound impressive. It is to show how the system grew under normal constraints, mistakes, and practical tradeoffs.

Home Next: Architecture

01 · Workspace and memory foundation

Define the workspace, memory model, and startup rules

This is where the system gets a home. OpenClaw seeds the workspace, the core markdown files define behavior, and durable memory is split from daily notes so context stays usable over time.

02 · Local foundation

Build the local machine around Claude, Codex, repos, and scripts

The laptop becomes the active execution layer. This is where agent sessions run, repositories live, commands get executed, and helper scripts begin to matter.

03 · OpenClaw on the VPS

Move memory and orchestration onto a private remote host

This stage moves the persistent layer onto a VPS, adds private connectivity, and turns OpenClaw into the durable cross-session system behind the local tools.

04 · Hooks and ingestion

Capture commits, session endings, and workflow context automatically

Global git hooks, Claude Stop hooks, parser fixes, and helper scripts start feeding the memory layer automatically so important context does not depend on manual copying.

05 · GitHub and publishing

Use GitHub as the version boundary and publishing path

GitHub becomes the external system of record for repositories, commits, documentation history, and static site publishing.

06 · Current state

Bring the local machine, VPS, hooks, agents, and GitHub together

The result is the current environment: local execution on the laptop, private remote persistence through OpenClaw, automation hooks, GitHub-backed publication, and a tighter security posture.

How each step gets built

1. Define the goal

Start with the problem the step solves. Say what broke, what was missing, and what running state should look like when it is done.

2. List the tools

Name the actual tools used, such as Claude, Codex, git, the shell, or any project script. Keep the list concrete.

3. Show the commands

Include the real commands or the exact sequence needed to get the step running. If something is manual, say that plainly.

4. Explain the security piece

State how the step stays safe, for example by using Tailscale, a provider firewall, narrow access, or other explicit controls.

Each entry should end with what changed, what still needs attention, and whether the result is safe to keep running as-is.