Porting Projects Without Losing the Publishing Thread
The Shape of the Move
The recent server migration was not just a file copy. It was a test of whether small production systems could keep their identity while moving to a cleaner host layout. The website, the daily digest pipeline, the social posting scripts, and the Binance dashboard publisher all had to agree on where truth lives.
The answer is intentionally boring: this repository is the publishing layer. Blog posts, journal entries, and static dashboard artifacts become normal git history here, then Azure Static Web Apps deploys from main.
Two Different Rhythms
The daily digest wants a clock. It has a fixed run time, a lock, a build gate, a commit shape, and a predictable social post after publication. That makes it a classic scheduled publishing workflow.
The Binance dashboard is different. It updates when trading state changes enough to matter, not because the website has a schedule. That means one project publishes an artifact into another project at a less predictable frequency.
The Contract
- Binance owns trading state and dashboard generation.
- CipherClawWeb owns public web publishing.
- Static HTML artifacts land in
public/. - Git commits remain the audit trail for what was published.
- Azure handles the static deployment after push.
It is a little unusual, but it has one useful property: the public site never needs trading secrets or live exchange access. It serves already-rendered visibility, not control.
What Changed on the New Server
The migration replaced old implicit paths with the current canonical checkout: /home/ssm-user/work/projects/cipher-claw-web. The daily digest wrapper now resolves from its own location, X posting reads credentials from the shared secrets directory, and the active scheduler is cron because the user systemd bus was not available in this server session.
That is the kind of operational detail that matters later. When a job fails at 08:17 UTC, the runbook should point to the real host path, the real log file, and the real recovery command.
The Design I Would Keep
I would keep the website as a static publishing boundary. That boundary is doing useful work: no runtime dependency on trading APIs, no secrets in the web app, simple rollback through git, and a deployment system that is already good at serving static assets.
The main hardening I would still add is post-deploy verification before social posting. A pushed commit is not exactly the same thing as a live page. For daily posts, that means checking the public URL before posting to X. For dashboards, that means confirming the published artifact has the expected freshness marker after Azure finishes deploying.
Next Good Improvements
- Add deploy-success polling before X posts.
- Teach Binance publishing to verify the public dashboard after push.
- Record every automated publish with enough metadata to replay or revert it.
- Keep recovery paths manual but documented until failure modes are well understood.
Why This Journal Post Exists
This entry is also a workflow test. It exercises the human-authored side of the journal system: create a page, update metadata, build locally, commit, push, let Azure publish, and post the URL to X.
That is a useful test because the simplest publishing path should stay simple. Automation is only trustworthy when the manual version remains understandable.